Name: [FIX] web_responsive: reach the apps menu the user actually opens

State: Killed

PR State: merged

PR Author: David Tran

PR Author Email:

PR: #671

Committer: David Tran

Committer Email: david.tran@tvtmarine.com

Commit: e46a1b8dc1602cbbd340d60efc50f28206ad657c

Description:

                                            [FIX] web_responsive: fix apps-menu toggle dead-end and flash bug

The apps-menu toggle button (button.o_grid_apps_menu__button) could go
permanently dead. AppsMenuAction is registered under the "menu"
client-action tag, so it can be mounted directly via doAction("menu"),
bypassing the apps_menu service's own openMenu() (the overlay path)
entirely. When that happens, the service's isOpening flag still turns
true (AppsMenuScreen's mount effect fires unconditionally) but
removeOverlay stays null, so the next click's closeMenu() finds
nothing to remove and does nothing - the button stays dead until the
action is dismissed some other way. A code comment claimed this path
was "unreachable, no live path to test" - that was false:
erponline-enterprise18/viin_customizer_web_responsive (auto_install:
True) reaches it via its own isolated action service, and this
module's own test suite already drives doAction("menu") through the
real action service elsewhere. closeMenu() now falls back to the real
"action" service: when the "menu" action is the current controller and
something is underneath it (breadcrumbs already exclude "menu"-tagged
controllers, so a non-empty array means a real prior screen), it
restores that screen. With nothing underneath (a bare doAction("menu"),
e.g. the boot fallback) the button stays a no-op by design - there is
nothing to reveal.

Separately, the previous commit's anti-flash fix (66a6a7d65d, passing
`open` down as a prop so the app grid renders in the same cycle the
screen mounts) was silently discarded for any upgraded user.
AppsMenu.setup() called useState() a second time whenever
session.apps_menu.is_redirect_home is true, recomputing `open` from
the router's menu_id and overwriting the prop entirely.
migrations/18.0.1.0.8/post-migration.py backfills is_redirect_home=True
for every upgraded user with no action_id - the dominant real
configuration, not an edge case - so any such user landing on a
non-root menu (menu_id != 0) got the one-frame empty-overlay flash
back. Collapsed to a single useState() call: the prop wins whenever
the caller passes it; the is_redirect_home fallback only applies when
AppsMenu is mounted without that prop.

Also removed a dead `browser.localStorage.setItem("redirect_menuId",
"")` write (and its now-unused import) - its only reader, onMenuClick,
was deleted by 66a6a7d65d; no other reader exists anywhere across
branding18, tvtmaaddons18, or erponline-enterprise18. Updated a stale
test comment describing the retired bus-round-trip open mechanism, and
dropped a stray blank line. Bumped the module version.

Two RED-before-green Hoot tests were added protecting each fix, both
confirmed failing on the pre-fix code and passing after, live on Hoot
desktop preset:
- "clicking the navbar apps button dismisses the menu action too, not
  only the overlay"
- "the is_redirect_home branch never overrides the open prop
  AppsMenuScreen always passes"

Before: filter=@web_responsive/apps_menu - 17 tests, 15 passed / 2
failed (both new tests red on the exact predicted assertions).
After: same filter - 17/17 passed. Full @web_responsive tag - 17/17
passed. Also manually verified the ordinary overlay open/close flow
live in the browser - no regression.
                                            

Branch: 18.0

Age:

Up-time: Not finished