The usual UI/UX convention is that a program shows a blinking cursor only when it has focus, so that if the user types something they can visually know which window the keystrokes are going to.
Thus, When a window loses focus, the expectation is that a blinking cursor disappears. Except for ancient X-windows systems (in which focus-follows mouse), giving focus to a window requires a click on it. Confusingly, Obsidian shows a blinking cursor even if the window doesn’t have focus, when the user’s cursor hovers over the Obsidian.
The unfortunate result is that the user sometimes sees the blinking cursor in obsidian and innocently starts typing, while their keystrokes get sent to another window and wreck havoc there (triggering esoteric shortcuts, closing windows, entering weird modes), until the user figures out what’s going on and then has to undo the damage.
This happens to me several times a day, and it’s infuriating.
Classic scenario: taking notes while watching a lecture on Youtube. Browser on the left, obsidian on the right. I switch the video to full-screen, and leave FS mode only when I want to write some notes in obsidian. When I exit full-screen, the browser still has focus but, if my mouse happens to be on top of the obsidian window, Obsidian shows me a blinking cursor as if it has focus and I just start typing. Depending on what keystrokes I enter until I realize my error, I may close browser tabs or do other damage by accident. Then I have to waste time undoing the damage, reloading the video, finding the seek time I was at, by which point I’ve lost my train of thought and can’t remember what I intended to write. It is maddening.
But this behavior definitely doesn’t happen with chromium (or anything else I use) in sway, and obsidian is electron-based, right? So It seems like it’s obsidian that’s doing something unusual, not that it’s a bug in sway.
the title bar at top of window shows focus (red=focused).
moving cursor over obsidian triggers a blinking cursor, even when obsidian doesn’t have focus.
typing while obsidian shows a blinking cursor sends keystrokes to the focused VIM window, even though obsidian is visually signalling that it is “ready” for input.
On linux, we only test/against support KDE and GNOME. It usually works in other DE and if it doesn’t, it’s probably problem of the desktop environment not ours.
I am sorry, but we are not going to look into this. I am going to leave this conversation open in the help section, perhaps somebody can point you in the right direction.
@CawlinTeffid , I tried it but no change. @cristian, can you say which specific compositor you’re using (sway/wlroots-based/other)?
both KDE/GNOME run on wayland by default on major distros, so we know wayland itself is probably not the issue.
Just wanted to add that I see the expected behavior on my end: the cursor disappears when the window is not in focus. I run the latest version of Pop_Os.
Perhaps it is a sway issue after all, and Obsidian is just the first reliable repro I’ve found so far. I have seen other types of weirdness, rarely and unreliably, and I didn’t make the connection until now.
Thanks for all the help, I’ll try to figure out a bug report for sway upstream.
