New pane does not become active when opened with link or switcher from pinned pane

Steps to reproduce

  1. Starting with a single pane, pin it
  2. Use the quick switcher to open another note, or activate a note link from the pinned note (either edit or preview mode)

Expected result

The pane with the newly-opened note should be focused and active

Actual result

The pinned pane remains active

Environment

  • Operating system: Windows
  • Obsidian version: 0.10.1

Additional information

This same behavior occurs when forcing a new pane to be created via ctrl-click from a pane that is not pinned, but that seems less problematic as that mirrors browser behavior when opening links in a new tab.

But clicking a link normally from a pinned pane (or using the quick switcher) seems closer in intent to a target="_blank" link, i.e. implying that the new pane should immediately become focused and active, rather than requiring extra clicks or keystrokes.

(Also, clicking a a note from the file navigation pane when a pinned pane is active causes the newly-opened pane to activate, which seems like reasonable behavior for links and the quick switcher to follow.)

1 Like

I agree with you that there are some incoherences depending on the way you look at it.

A somewhat related issue is that if you have all your panes pinned, it seems as though opening something (whether via link, file manager, or quick switcher) should open a new pane adjacent to the current or most recently active pane, rather than one at the far end of the workspace. I use the sliding panes plugin and often have 8 or 10 panes open, and I prefer to keep them pinned, but when I open something and forget to split first or ctrl-click/ctrl-enter, it ends up very far away and trying to reorganize the splits is a serious pain (pane?).

It seems to me that the root causes of this are likely that 1) getUnpinnedLeaf() should fall back to splitActiveLeaf() rather than creating a new top-level split, at least in the case where the active leaf (or most-recently used leaf) is top-level. (And even then, it should probably create the new top-level split as close as possible to the active/recent leaf.) And 2) splitActiveLeaf() should probably always set the newly created leaf to active.

I think that this would largely preserve the current behavior of Obsidian in most use cases. The only thing that might behave differently is if you are opening multiple links in edit mode using the keyboard with ctrl-alt-enter to open them in new panes. That is the only case I can see where making the new pane active would have an effect on needed user behavior, since to use the keyboard on multiple links you’d need to keep switching back to the previous pane.

Will be fixed 0.10.3

1 Like