The Proven Spacebar Bug

Hello,

I am using the obsidian-reveal-active-file plugin. I find this plugin more effective than Obsidian’s built-in feature. However, when I use the plugin and press the space bar while typing the file name, the file name is automatically saved. This annoying bug was discussed in the obsidian-reveal-active-file GitHub forum, and it was determined that the issue is caused by Obsidian. I’m sharing this bug so that the valuable developers can see and address the issue. Thank you.

Link of the topic: Typing a new note name will save the new title when hitting space · Issue #22 · shichongrui/obsidian-reveal-active-file · GitHub

By the way, even if I disable the obsidian-reveal-active-file plugin, the issue persists. I need to disable the file explorer to resolve the issue.

We have a bug report template, can you please repost this and make sure you follow the bug report template with reproducible steps in the sandbox vault. Thanks!

Hello,

I’m sorry, but your bug report template is too long and unnecessarily complicated. I’ve already shared the relevant GitHub issue where the problem is discussed. If the developers review the issue, they will have sufficient information and insight there.

By the way, maybe you reconsider the decision to ignore an obvious bug just because I didn’t follow the template, as this approach could do more harm than good for Obsidian. Thank you.

I looked into the github issue and I did not quite understand it nor if it is an obsidian’s core problem.
I am sorry, but If you want this be considered as bug, we are gonna need a bug report following the template.

Omg, are you seriously claiming that you read the discussion in the issue and didn’t see this message?

This led me to believe that the Obsidian’s internal “Files: Reveal current file in navigation” command is the one that traps focus to the Files sidebar, but in such a way that the focus is brought back to it whenever “space” is hit. Similarly how you can press a button on a website by hitting space as long as it has focus. So my conclusion is that the bug seems to be with the “Files: Reveal current file in navigation” command, and not this plugin itself. Therefore, the fix should take place by the Obsidian team, not the plugin author.

There might be workarounds to resolve the issue without waiting for Obsidian to fix the issue, as Pane Relief manages to bypass focus stealing, but I didn’t have time to look into that.

My initial workaround was to hold space while typing the title, but it’s not possible on the mobile, so I resorted to locking focus using the Pane Relief plugin.

Taking a quick look at the source code for the plugin, my best guess is that the file-open event is (for some reason, possibly a baseline bug) being fired by Obsidian when that first space is hit.

As far as I remember from my debugging, the file-open event is not fired by hitting space, but rather by the focus being taken away from the title bar, which is itself caused by hitting space after a file has been previously revealed.

I’m not familiar with Obsidian plugin development, but I wonder if that handler can be updated to do a check to see if the file title input currently has focus, and if so, don’t call reveal()?

None of the code in the plugin seems to be triggered at the time the focus is stolen from the title input. The stage is set before that by calling reveal(), and subsequently file-explorer:reveal-active-file before that.

So to circumvent the issue, the focus should be “locked” somehow while the title input is focused. I didn’t have time so far to dig through the docs and I’m quite unfamiliar with Obsidian’s API/architecture. If anyone can point me to the right direction regarding the APIs we’d need to use, I’m happy to do that. I’m sure Pane Relief source code might help here."

If you really don’t want to see it, there’s nothing I can do. But the developer “lightheaded,” who commented on the issue, has clearly and explicitly described the problem. He also mentioned that the issue is caused by Obsidian. So what’s the point of requesting a “bug report template” after this?

I read it and I am not convinced there’s a bug there.
That command is meant to bring the focus to file explorer.

If there is a problem that is reproducible in the sandbox vault, I’ll take the bug report.
If there is a problem with the API, the developer can open a thread in Developers: Plugin & API .

Yes, there is definitely an issue with the spacebar for Obsidian’s “File Explorer.” Alright then, I’ll try testing it in a sandbox when I have time. But I have a request from you as well. Could you please download the attached plugin to your application and try typing a title in any note? Most likely, you’ll encounter the same issue when you press the spacebar while typing the title.

Thank you…

On mac, following finder standard UI interactions, When file explorer is the active tab and there is a file selected, we use space to trigger file rename.

Sorry we don’t take bug reports involving third party plugins.
Looking at the screenshots in that github issue, I believe that plugin uses “Files: Reveal current file in navigation” but does not bring the focus back to the file.

I’m not asking you to test a third-party plugin. As explained in the GitHub issue, the problem isn’t with the plugin; it’s related to Obsidian’s File Explorer. When trying to enter a note title, the writing focus is lost after pressing the spacebar following the first word. I’m experiencing this issue even after disabling the “Automatically Reveal Active File” plugin.

I don’t know if the plugin is triggering the issue. But if you at least install and test the plugin, I’m sure you’ll encounter the same problem, and even if you disable the plugin, you won’t be able to resolve the issue.

On that same vault that you are using perhaps you just need to restart obsidian after you have disabled the plugin. Because some plugin don’t cleanup well.

I can’t reproduce the problem that you describe in the sandbox vault.

I have also noticed that there are several issues opened in that repository all dealing with the note not being in focus (because that plugin causes the file explorer to be in focus)

Thank you very much for your responses and attention. Love to the Obsidian family…

Thanks for pointing this thread out to me @Paladin, and thanks for sticking through the conversation @WhiteNoise. If I recall correctly, then I was able to reproduce the issue without any community plugins installed. I can take a look whether it’s still the case, but I can’t commit on a timeline.

For what it’s worth, at the time of my testing, I was fairly confident that the behaviour was not intentional as the focus was seemingly split between two places - cursor (which is then indicator for focus) was in the title textbox, but hitting space caused the focus to jump back to the file explorer. This left me with an impression of a schizophrenic focus behaviour, where it’s present partially in two places at the same time.