Steps to reproduce
- Starting from a single pinned pane in either source or preview mode, open a file with the quick switcher
- Close the freshly opened pane
Expected result
The previous pane should be focused in the edit area with cursor at the previous position (if it was in source mode), or the pane should be scrollable with up/down/pageup/pagedown (if it was in preview mode).
Actual result
The pane is visually rendered as active, but does not respond to navigation keystrokes or typing (if in edit mode).
Environment
- Operating system: Windows
- Obsidian version: 0.10.6
Additional information
This appears to be the result of trying to fix the various setActiveLeaf() problems by changing the commands that call setActiveLeaf(), instead of having setActiveLeaf() ensure focusing in the target. See the previous discussion for more details, including the workaround code I’m using in a plugin. (I was hoping to be able to drop that workaround with 0.10.6, but it’s still needed.)
This should probably be fixed in setActiveLeaf(), as otherwise there will be lots of corner cases like this one where things don’t work properly otherwise. (For example, a layout change with no active leaf is likely another such corner case.)
Yet another corner case: plugins that use setActiveLeaf() will also be broken, e.g. the Cycle Through Panes plugin. Although it has a workaround for edit-mode panes, it does not have the workaround for the scrolling issue described in the previous bug.
Rather than include workarounds in every possible corner case (and plugin!), it would be better if this behavior were the responsibility of setActiveLeaf(), even if it needs to be delegated to some other object(s) to do the actual state setting.
Btw, this seems to be part of a general pattern indicating that there isn’t anybody testing Obsidian who prefers the keyboard over the mouse. These kinds of problems where there’s just no way to reasonably get something done without switching to the mouse are pretty widespread… and I’m only reporting on the ones that are bad enough, often enough, to regularly interrupt my workflow. (For example, I haven’t yet reported the fact that you can’t confirm a delete with the keyboard because I don’t delete often enough for it to be a serious annoyance… but it’s definitely still an annoyance.)
I’m not visually impaired myself, nor do I have the other sort of issues that make mousing a challenge, but I have to imagine that these kind of “keyboard randomly stops working” problems would have to be a LOT more of an annoyance for people with those impairments than they are for me.
Should I be reporting more accessibility bugs at the present time, or is it not on the roadmap until later?