2064732 - Invisible doorhanger button stays clickable

Status: NEW

(Firefox :: Menus, defect)

Description

[Frederik Braun [:freddy]]

Sometimes Firefox restarts automatically on its own. It always happens while I type something, so now I have a suspicion that there's a "update now" dialog coming up while I type that has autofocus or such and I am inadvertently triggering it.

I think the culprit is that I use the omnipresent "CTRL+U to cut" key combination and the fact that the dialog is triggered by this even when it isn't showing.

(Disclaimer: I used an LLM to help collect the following evidence. I had it run tests to verify its claims, but it might contain subtle mistakes)

After the update-restart doorhanger is dismissed, the panel closes but the
<popupnotification> keeps hidden=false and a live .notification, so
"Update and restart" is still an accesskey target with nothing visible on
screen. One keystroke typed in a web page restarts the browser and loses
in-progress typing. Hit in normal use on macOS, where the chrome accesskey
modifier is plain Ctrl and Ctrl+U is a common readline/emacs habit.

STR

1. In the Browser Console (devtools.chrome.enabled):

   const { AppMenuNotifications } = ChromeUtils.importESModule(
     "resource://gre/modules/AppMenuNotifications.sys.mjs");
   AppMenuNotifications.showNotification("update-restart",
     { callback: () => console.log("MAIN ACTION -> would restart") }, { callback(){} });
   

2. Click Dismiss. The panel closes, only the hamburger badge remains.
3. Click into a text field on any page and press Ctrl+U (macOS) / Alt+U
   (Windows/Linux — ui.key.chromeAccess).

Expected: nothing; there is no visible button.
Actual: the hidden button#main-button is clicked and the main action runs.
With a real pending update this restarts Firefox.

Cause

PanelUI._hidePopup()
hides the panel but never resets the notification elements;
_clearNotificationPanel()
runs only when all notifications are removed. Compare
PopupNotifications._clearPanel(),
which does this cleanup on popuphidden.

Verified on a local mozilla-central build; the mochitest a11y-checks harness
also flags it (unable to perform a11y checks on hidden node: id: main-button).

Happy to share a questionable, vibecoded test on request, but don't think I can commit cycles beyond that :)

Comment 1

[Stephen Thompson [:sthompson]]

Sounds similar to bug 1945032 since a hidden chrome element's accesskey is being triggered. Did the restart-to-update notification get a new/changed accesskey?

Comment 3

[Jan Brasna [:janbrasna]]

There has been a change in bug 2024692 if you want to try a buildid before/after and let it present the same dialog, to see if it's the actual regressor?