PR State:
merged
PR:
#675
Commit:
66c1a36b1960c60db9cfc85bf56a3c6d8a2063f4
[FIX] web_responsive: dismiss the apps menu when a search result is chosen
Searching the apps menu and choosing a result appeared to do nothing: the menus
filtered, but clicking one or pressing Enter left the user where they were.
Navigation was in fact succeeding. The controller changed and the URL moved to
the target, with no JS error and every RPC returning 200 - but the full-screen
overlay stayed mounted over the destination and, being position:fixed with
pointer-events:auto, swallowed clicks on the view underneath.
The overlay must be dismissed explicitly. When the apps menu became an
overlay-service render independent of the action stack, dismiss() was added
before selectMenu() on the app-icon path but not on the search paths, and
core's selectMenu() only mutates the action stack. Three call sites needed it,
not one: the canonical search bar (whose handler the Enter key also reaches, so
click and Enter are one path), the fuse variant that inherits it, and the
command-palette variant, which fails through a different mechanism because
openMainPalette was passed no onClose.
The command-palette path dismisses only when a menu was actually selected.
onClose fires on every palette close, Escape included, so dismissing
unconditionally would tear the apps menu down when a user merely backs out of
the palette - trading one surprise for another. It also registers that callback
once per open palette session: core's command service ignores onClose on every
call after the first while its palette is open, so re-passing it per keystroke
orphaned a patch layer on the session-lifetime menu service each time.
The app-tile route, which every core tour uses to reach an app, was already
correct and is untouched.
Signed-off-by: David Tran <david.tran@tvtmarine.com>
Branch:
18.0