[Bug / UX Issue] Pinning context-dependent sidebar views (Outline, File Properties, Backlinks) leads to a silent "No headings found" trap

[bobrock]

[Bug / UX Issue] Pinning context-dependent sidebar views (Outline, File Properties, Backlinks) leads to a silent “No headings found” trap

Environment

• Obsidian Version: v1.5.x – v1.13.x+
• Platforms: Desktop (Windows, macOS, Linux) & Mobile

---

Steps to Reproduce

1. Open Obsidian in any vault.
2. Open or switch to a non-Markdown view (e.g. an Obsidian Base .base, a Canvas .canvas, Graph view, or an empty tab).
3. In the right sidebar, switch to the Outline view (or File Properties / Backlinks).
4. Pin the sidebar tab (either by clicking the pin icon in the tab/leaf header or via the Toggle pin command palette/hotkey).
5. Switch back to the main workspace and open any standard Markdown note containing valid H1/H2/H3 headings.

---

Expected Behavior

Either:

• The Outline view dynamically displays the headings of the active note in the editor, OR
• If pinning is intended to freeze the view to a specific note, the UI should clearly indicate which note it is pinned to, and explicitly warn the user if it is pinned to a null / detached state (e.g. “Outline is pinned to [No File] — click to unpin and follow active editor”).

---

Actual Behavior

• The Outline view remains permanently frozen on an empty state, displaying: “No headings found.”
• Opening any note with valid Markdown headings still produces “No headings found.”
• Users naturally assume:
  • Their note syntax or heading markdown formatting is broken.
  • A CSS snippet or custom theme is hiding headings.
  • The internal metadataCache has corrupted.
  • A community plugin broke the parser.
• There is zero visual indication or banner explaining why headings are missing.

---

Technical Root Cause

In Obsidian’s architecture, OutlineView (as well as FilePropertiesView, BacklinkView, and OutgoingLinkView) inherits from FileView and is hosted inside a WorkspaceLeaf.

1. When a leaf is pinned (leaf.pinned = true), the base FileView sets isLeafBoundToFile = true.

2. When the user navigates between notes, the workspace triggers onFileOpen(file). However, FileView’s base implementation contains:

   function(e) {
     this.isLeafBoundToFile || (e && e instanceof TFile ? this.loadFile(e) : this.loadFile(null))
   }
   

3. Because isLeafBoundToFile is true, loadFile(file) is completely bypassed.

4. OutlineView.getHeadings() evaluates this.file, which remains null (or bound to whatever note was open at pin time). Consequently, it returns [] and mounts this.emptyEl (“No headings found.”).

---

Why This Is a Serious UX Trap

1. False Error State: The UI communicates a document error (“No headings found” in the active note) rather than a panel state (“Panel is detached/pinned”).
2. Troubleshooting Frustration: Users waste considerable time troubleshooting Markdown formatting, frontmatter, snippets, or disabling plugins before discovering that a tiny pin icon on a sidebar tab was accidentally engaged.
3. Semantic Inconsistency of “Pin”:
   • In the Main Workspace, “Pin Tab” means “Do not replace this tab when navigating/following a link” (tab lifecycle management).
   • In the Sidebar, “Pin Tab” becomes “Permanently freeze inspection to this specific note or null”, without displaying the target file name.
4. Widespread Across Context Views: The same silent freezing occurs on:
   • file-properties: Shows outdated frontmatter/metadata while editing a different note.
   • backlink / outgoing-link: Freezes linked references on the previously pinned note.

---

Suggested Improvements

1. Clear Empty/Detached State Banner:
   When a sidebar view is pinned and this.file is null (or differs from app.workspace.getActiveFile()), show an informative banner inside the view:

   Outline is pinned (detached from active editor). [Unpin] to follow active note.

2. Header Context Label:
   When pinned, display the bound file name in the sidebar header or tab tooltip (e.g. Outline (Pinned: MyNote) or Outline (Pinned: None)), making the locked context immediately apparent.

3. Auto-Unpin or Prevent Binding to Null Contexts:
   Do not allow isLeafBoundToFile to bind to null if the pin action is triggered while an unsupported view (Base/Canvas/Empty) is active.

[WhiteNoise]

@bobrock

• If pinning is intended to freeze the view to a specific note, the UI should clearly indicate which note it is pinned to, and explicitly warn the user if it is pinned to a null / detached state (e.g. “Outline is pinned to [No File] — click to unpin and follow active editor”).

First, there is an indication that the tab is pinned.
Second if you hover over tab, it’ll tell you which file it is pinned to.