I think this issue likely arises from the fact that
app.workspace.setActiveLeaf() does not support setting a sidebar document as the active leaf, and presumably commands are always applied to the active leaf.
setActiveLeaf() checks whether the new leaf’s
getRoot() is equal to the workspace root, but a sidebar document’s
getRoot() is the top-level split of its associated ribbon.
setActiveLeaf() should be checking for
leftSplit as well as
rootSplit. I’ve tested this with a quick monkeypatch from the developer console, and it allows both commands and hotkeys to work, and also allows the cycle-through-panes plugin to cycle properly, even cycling through the sidebar documents.
There does seem to be one other glitch that it doesn’t fix, though: toggling the edit mode of a sidebar document causes the first pane in the main split to become active. Clicking again in the sidebar document returns it to an active state, however.
There is also no visual indication that a sidebar document is active, and activating a document whose tab isn’t selected doesn’t cause that tab to become selected. Similarly, selecting the tab of a sidebar document doesn’t cause it to become active.
So, it looks like more work will be needed to fix this besides just making it possible for a sidebar pane to be set active… although just supporting that would be a big help.
While investigating this issue I also discovered why the history behaves so oddly in 0.9.x; it apparently includes navigation between panes as part of the history. It sounds like that might have been changed in 0.10.x, though.