You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PWA: the update banner's announcement is swallowed while a dialog is open #485
#483 makes everything except the topmost dialog inert (that is what stops a second dialog being reachable, and what closes the a11y hole aria-modal only hints at). One consequence is worth deciding deliberately rather than inheriting.
UpdatePrompt (web/src/pwa/UpdatePrompt.tsx:61) is a persistent role="status" aria-live="polite" banner with Reload / Later buttons, mounted inline under #root (App.tsx:80) — a document.body child, so it goes inert whenever any dialog is open.
If a service-worker update lands while the user has a dialog open:
the banner is unclickable until the dialog closes, and
it is out of the accessibility tree, so its aria-live announcement is never made — and un-inerting later does not re-announce it.
(1) is arguably correct and worth keeping. Reloading mid-form would discard whatever the user is typing, so a Reload button that cannot be hit while a dialog is open is a feature. (2) is a real, if narrow, regression: a screen-reader user gets no notification at all, rather than a delayed one.
Found by an internal reviewer during #483. Not fixed there, because the options each have a cost worth weighing separately:
Re-announce when the last dialog closes — smallest honest fix; needs UpdatePrompt to know the modal state, or a re-mount trigger.
Exempt opted-in elements from inertness (data-modal-exempt) — general, but a reachable control outside the modal partly defeats the point, and the focus trap would fight it.
Accept it and document — defensible; the banner is still there when the dialog closes, just never announced.
Also noted, lower risk: AppLayout.tsx:93-108's farm-load-failed role="alert" banner is inerted the same way, but it is already on screen before any dialog opens, so nothing is missed — only temporarily unclickable, which is the correct modal behaviour.
No test covers the combination today: UpdatePrompt.test.tsx renders it standalone, and tools/simulation/ui/specs/pwa.spec.ts never has a dialog open at the same time.
Activity
fix(e2e): render every fetched lot page before judging identity (#506, …
test(e2e): verify in a real browser that a dialog hides the live regi…
fix(web): stop the dialog open count leaking when a dialog is reopene…
feat(web): convert Dialog and useConfirm to MUI Dialog (#892)
fix(web): give the expanded chart back its Shift+Tab, its open-count …