Typing a new note name will save the new title when hitting space

[mbentley]

At least for me on MacOS, when I am typing a new note name and I hit space, it saves the file name with this plugin enabled. I am not sure if it was happening before I updated (I don't think it was) but it's happening with v1.3.3 that was just released.

I can reproduce this by creating a new vault, enabling just this plugin and then trying to create a new note.

[3DManuH]

I can confirm this issue. Hence i can't add space in file name currently when using the plugin.

[xjjon]

Same, I took a look through the code and couldn't find anything that would cause this so I suspect it is due to some behavior change with new version of Obsidian.

[madeinchema]

Observed behaviour:

When the user creates a new note, its title is "Untitled", and it is immediately highlighted.

• With the plugin enabled: When the user types one word, then hits the space bar, the note is updated in the file explorer pane (renamed, rearranged, although not highlighted by the plugin).

• With the plugin disabled: Only when the user takes focus away from the title is the note updated in the file explorer pane.

• This issue does not happen if the file explorer pane is closed (i.e. the user can create a new note, and keep writing the title with spaces without interruption).

[technodrome]

+1. Too bad this hasn't been fixed since May.

[shichongrui]

PRs are welcome.

[ggteixeira]

PRs are welcome.

I'd be glad to help, but first I'd rather know if this plugin is still being mantained (cc @shichongrui)

[shichongrui]

I no longer use it and thus don't spend time actively working on it. But it still seems to get a fair amount of use, so I'm willing to look at PRs, or transfer ownership as I've done with other plugins I created and no longer use.

[ggteixeira]

Thanks for replying @shichongrui! I understand. I'll work towards fixing this issue. If I succeed — meaning that I'm capable of keep tinkering the code — you can transfer its ownership to me if you want to 😄

[hbock-42]

I can confirm, when creating new note and adding a title, it saves the file after first hitting space. I have to come back to add the rest of the title.

I disabled the plugin and it solved the issue

[lightheaded]

I looked into it a bit, and it seems that the issue can also be reproduced without this plugin. When you start typing a title, and then hit use the command "Files: Reveal current file in navigation" (what is referred to as file-explorer:reveal-active-file in code), then the same behaviour happens. So this is an Obsidian-related issue rather than the plugin's. This can probably be solved by temporarily locking focus like the Pane Relief does, but I imagine this is much more effort compared to what this plugin currently does.

[ggteixeira]

Thank you for digging into it, @lightheaded!

[jasonmansfield86]

@lightheaded - Maybe I'm misunderstanding what you tested, but that doesn't seem relevant to the actual issue here?

The complaint is that hitting space while typing in a new title: (1) causes the file to immediately be updated in navigation with the new name and (2) steals focus.

Yes, manually running the command may cause those things to happen too, but this still shouldn't be happening automatically just because space was hit - that's the bug.

[jasonmansfield86]

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.

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()?

[lightheaded]

@lightheaded - Maybe I'm misunderstanding what you tested, but that doesn't seem relevant to the actual issue here?

The complaint is that hitting space while typing in a new title: (1) causes the file to immediately be updated in navigation with the new name and (2) steals focus.

Yes, manually running the command may cause those things to happen too, but this still shouldn't be happening automatically just because space was hit - that's the bug.

Sorry for being perhaps too brief in my description.

I tried to isolate the root cause. I started commenting out code and trying to reproduce the issue to see what parts of the code were causing it. I found out that commenting out this line removes the issue.

(this.app as any).commands.executeCommandById('file-explorer:reveal-active-file');

Which makes sense, as this is the line that delivers most of the value that this plugin offers.

Now, this command can be executed without the use of this plugin as well. So I disabled the plugin, and tried to reproduce the issue outlined by the issue author. I used the "Files: Reveal current file in navigation", then created a new file, and as soon as I hit space, the focus jumped back to the Files sidebar (and as a result of the loss of focus, the title gets updated / file gets saved).

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 reoslve 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.

Screen.Recording.2024-07-22.at.09.34.56.mov

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.

[jasonmansfield86]

@lightheaded - I understand your findings now, thanks for the detailed follow-up.

I took a look at the pane-relief source code, and it appears that the way it "locks" the focus is actually just regularly setting the focus back to the main document via setActiveLeaf.

This line, which I just tested out in the developer console, seems to do the trick, though I admit I haven't checked the doc of either method involved to confirm that this is an appropriate use case.

app.workspace.setActiveLeaf(app.workspace.getUnpinnedLeaf(), false, true)

[Medullitus]

Any progress please?

[Medullitus]

https://forum.obsidian.md/t/the-proven-spacebar-bug/87745

[Medullitus]

@lightheaded - Maybe I'm misunderstanding what you tested, but that doesn't seem relevant to the actual issue here?
The complaint is that hitting space while typing in a new title: (1) causes the file to immediately be updated in navigation with the new name and (2) steals focus.
Yes, manually running the command may cause those things to happen too, but this still shouldn't be happening automatically just because space was hit - that's the bug.

Sorry for being perhaps too brief in my description.

I tried to isolate the root cause. I started commenting out code and trying to reproduce the issue to see what parts of the code were causing it. I found out that commenting out this line removes the issue.

(this.app as any).commands.executeCommandById('file-explorer:reveal-active-file');

Which makes sense, as this is the line that delivers most of the value that this plugin offers.

Now, this command can be executed without the use of this plugin as well. So I disabled the plugin, and tried to reproduce the issue outlined by the issue author. I used the "Files: Reveal current file in navigation", then created a new file, and as soon as I hit space, the focus jumped back to the Files sidebar (and as a result of the loss of focus, the title gets updated / file gets saved).

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 reoslve 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.
Screen.Recording.2024-07-22.at.09.34.56.mov

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.

Hello. Can you please write here: https://forum.obsidian.md/t/the-proven-spacebar-bug/87745

[Medullitus]

@lightheaded - I understand your findings now, thanks for the detailed follow-up.

I took a look at the pane-relief source code, and it appears that the way it "locks" the focus is actually just regularly setting the focus back to the main document via setActiveLeaf.

This line, which I just tested out in the developer console, seems to do the trick, though I admit I haven't checked the doc of either method involved to confirm that this is an appropriate use case.

app.workspace.setActiveLeaf(app.workspace.getUnpinnedLeaf(), false, true)

Hello. Can you please write here: https://forum.obsidian.md/t/the-proven-spacebar-bug/87745

[2VVS]

It would be nice to have this issue resolved someday.

The default way of right-clicking on the note's name (in the top menu breadcrumb) at the top of a note, then selecting "Reveal file in navigation" option has been a blessing so far.