macOS: fix Home activation and inconsistent sidebar / Navigate menu actions #417

Problem

The macOS sidebar and Navigate menu do not consistently activate the destination/action their labels imply. Reported by the user: clicking Home from a content submenu does not return to the Home screen.

Audited d6da97295b69a28764aaa518091d354045e6ef57. Findings below are verified by tracing the shipping source; native UI reproduction is still pending. No app code was changed for this audit.

Findings and reproduction cases

1. Home activation does not return to its root (primary report)

1. Open a movie/show or View All destination from Home.
2. Click Home in the sidebar.
3. Expected: the Home root is displayed.
4. Current source behavior: Home remains selected, so the selection-change observer does not run, and there is no explicit row activation handler to pop the stack.

Also test Home → detail → another sidebar destination → Home. The selection does change in this case, but the handler never clears navigation.homePath, so the retained detail is shown again instead of the Home root.

When Search is presented over an already-selected Home destination, clicking Home also has no selection-change event to dismiss Search.

Evidence: selection observer, lines 89–91, selection handler, lines 313–337, label/tag-only sidebar rows, lines 378–385, retained Home path, lines 450–461.

2. Navigate → Back exits Search instead of popping a search result

1. Search for content and open a result detail (or a deeper detail).
2. Choose Navigate → Back / ⌘[.
3. Expected: pop one search navigation level, keeping the query/results available.
4. Current source behavior: macNavigateBack() calls dismissMacSearch() whenever Search is presented, which clears both the query and the whole search path and restores the underlying browse destination.

Escape is explicitly documented as dismissing Search; the menu Back command should have a distinct stack-pop policy. Compare the native in-stack Back button with ⌘[ during UI validation.

Evidence: Back implementation and search dismissal, lines 339–375, documented Escape behavior.

3. Navigate → Offline can leave Search visible

1. Select Offline.
2. Present Search using ⌘F.
3. Choose Navigate → Offline / ⇧⌘D.
4. Expected: show Offline and dismiss Search.
5. Current source behavior: the command only assigns macSelection = .offline. Because Offline was already selected, the observer does not run and dismissMacSearch() is never called.

Clicking an already-selected sidebar row while Search is presented has the same general weakness.

Evidence: Offline command, lines 181–190, selection observer.

4. Navigate menu availability does not reflect whether actions can run

Back is enabled whenever authenticated, including a browse root with an empty path. Search and Offline are also enabled during video playback even though focusSearch() and the Offline command reject those requests. Back normally does nothing during playback too.

Expected: menu validation reflects actual availability, or an enabled command performs a deliberately defined transition. Preserve the current playback protection rather than interrupting media accidentally.

Evidence: menu validation, lines 52–69, Back availability, Search guard, Offline guard.

Acceptance criteria

• Explicit Home activation reaches Home root, including reselection, returning from another section, and Search over Home.
• Explicit sidebar/menu destination activation dismisses Search even if the underlying destination is already selected.
• ⌘[ / Navigate → Back pops one search detail level before exiting Search; Escape retains the documented dismissal behavior.
• Back is disabled when no back action is available. Search/Offline availability agrees with their playback guards.
• Add transition-policy coverage plus a native macOS semantic/Accessibility regression for these interactions; verify mouse and keyboard actions agree.
• Preserve backend/session isolation, music playback, and intentional Escape behavior.

Related work / scope

• macOS: reset pushed music detail when switching sidebar pivots #296 already tracks switching music sidebar pivots while a pushed music detail remains visible. Cross-link rather than duplicate that implementation.
• macOS: editing the toolbar search while a result's detail is open doesn't return to Search results #334 fixed query edits under a pushed Search result; do not regress it.
• Mac shell/sidebar redesign pass #232 was the completed Mac shell redesign, not an open tracker for these defects.
• Existing RootNavigationCoordinatorTests cover shared push/pop/reset and search-query behavior, and MacSidebarPolicyTests cover catalog/restore policy. They do not exercise the Mac shell's explicit destination activation and menu dispatch cases above.