Bug: Extension optional permissions popup triggered from a browserAction popup may get hidden while the user may assumes it got closed because the "Allow" or "Deny" buttons have been clicked
Status: NEW
Priority: P3
Created: 2022-04-28 12:21:33+00:00
Resolved: 2022-06-30 23:19:16+00:00

We noticed this bug while investigating an issue that QA caught while testing multi-account-container integration with Mozilla VPN.

The STR to trigger it with multi-account-container is a bit involuted and requires both multi-account-container and Mozilla VPN to be installed, and so I'll try to put together a reduced test case or test extension to make it easier to reproduce the bug.

In the meantime:
- I'm linking the Jira ticket filed by the QA as a "See also"
- I'm linking [here a short screencast](https://youtu.be/3vfrbNBstUg) that shows:
  - the STR I used to trigger the issue locally
  - and that the permissions doorhanger is actually getting hidden and not closed because the "Allow" button received the click event (instead the permissions doorhanger magically reappear after a "blur and then focus" of that window when I move the mouse out of that screen and than back to it again at the end of the screencast)

The following is a stack trace I collected while reproducing the bug using some trace logs set in the Browser Toolbox to pinpoint what was actually hiding the extension permissions' popupnotification:

```
"PopupNotifications hidePanel, panel id: notification-popup" 

@debugger eval code:1:74
PopupNotifications_hide@resource://gre/modules/PopupNotifications.jsm:882:9
anchorVisibilityChange@resource://gre/modules/PopupNotifications.jsm:745:12
UpdatePopupNotificationsVisibility@chrome://browser/content/browser.js:3322:24
_on_focus@resource:///modules/UrlbarInput.jsm:2934:19
handleEvent@resource:///modules/UrlbarInput.jsm:426:23
doFocus@chrome://global/content/elements/panel.js:231:14
on_popuphidden@chrome://global/content/elements/panel.js:270:13
handleEvent@chrome://global/content/customElements.js:466:27
EventListener.handleEvent*MozPanel@chrome://global/content/elements/panel.js:25:12
showSubView@chrome://browser/content/customizableui/panelUI.js:463:32
showWidgetView@resource:///modules/CustomizableUI.jsm:2065:25
handleWidgetCommand@resource:///modules/CustomizableUI.jsm:2083:12
```

Based on this stack trace it seems that the permissions popup notification is being hidden because:
- the urlbar was focused when we opened the browserAction popup (which should be what have originally triggered the "`handleWidgetCommand` -> `showWidgetView` -> `showSubView`" call visible at the bottom of the stack trace)
- the browserAction popup calls `browser.permissions.request` to request to the user to grant the missing "proxy" permission
- the permissions popupnotification gets opened and the user goes to click the "Allow" button
- as soon as the browserAction popup loses the focus, it gets auto-closed and based on the stack trace it seems that [`MozPanel.on_popuphidden` is trying to move the focus back to where it was before](https://searchfox.org/mozilla-central/rev/86c98c486f03b598d0f80356b69163fd400ec8aa/toolkit/content/widgets/panel.js#233) the browserAction popup has been opened
- the element previously focused was the `Urlbar`, and so from the MozPanel.on_popuphidden method we end up calling `Urlbar._on_focus`

The [`Urlbar._on_focus` method seems to be what is hiding the permissions popupnotification, which is also explicitly state in an inline comment from that method](https://searchfox.org/mozilla-central/rev/86c98c486f03b598d0f80356b69163fd400ec8aa/browser/components/urlbar/UrlbarInput.jsm#2949-2955):

> // Hide popup notifications, to reduce visual noise.

It is also worth a mention that QA seems to have been able to reproduce this only on Linux
(which is also the platform where I've investigated it).

I'm filing this into "Firefox :: Address Bar" because UrlbarInput.jsm seems to be where the popup notification are actually being hidden, but feel free to move it into another bugzilla component if it would fit better into what the bug is related to and which are the internals involved in triggering it.