1546016 - Persistent red rectangle on hamburger menu after dismissing a doorhanger that appeared while another doorhanger was being shown

Status: NEW

(Firefox :: Toolbars and Customization, defect, P2)

Description

[Rob Wu [:robwu]]

STR:

1. Open a new profile of Firefox Nightly.
2. Open a private browsing window.
   --> The "Change to extensions in Private Windows" doorhanger will appear.
3. Install any extension (e.g. from https://addons.mozilla.org/ ).
   --> The "[extension name] has been added to Nightly" post-install doorhanger will appear, and replace the previous one.
4. Click on "Okay, Got it" to dismiss the doorhanger.
5. Look at the hamburger menu button.

Expected:
Any of the following:

• The hamburger menu button looks normal, without any badges.
• The previous doorhanger reappears.
• A badge appears on the notification, and clicking on the hamburger menu activates the previous doorhanger.

Actual:

• A red rectangle appears on the hamburger menu, to draw attention.
  Upon clicking on the hamburger menu button, no notification is being shown.
  Upon closing the hamburger menu, the rectangle reappears.

Note that the bug also occurs if step 2 and 3 are swapped.

Comment 1

[Rob Wu [:robwu]]

In bug 1491438, the onDismissed callback was introduced, but only called when a notification has explicitly been dismissed.
Should this also be called at other places where the dismissed flag is set to true?

• Here: https://searchfox.org/mozilla-central/rev/52b651e168a5b3a923bed0ef977a3fd27c5dd713/toolkit/modules/AppMenuNotifications.jsm#73
• And probably not relevant for this bug, for good for consistency nonetheless, here too: https://searchfox.org/mozilla-central/rev/52b651e168a5b3a923bed0ef977a3fd27c5dd713/toolkit/modules/AppMenuNotifications.jsm#155

A problem with calling onDismissed when implicitly dismissed is that the private browsing doorhanger could disappear without explicit user interaction, via:

• https://searchfox.org/mozilla-central/rev/52b651e168a5b3a923bed0ef977a3fd27c5dd713/browser/modules/ExtensionsUI.jsm#536-539
• https://searchfox.org/mozilla-central/rev/52b651e168a5b3a923bed0ef977a3fd27c5dd713/browser/modules/ExtensionsUI.jsm#553

From the AppMenuNotification's API point of view, calling onDismissed after setting dismissed = true seems logical.
However, from the API consumer's point of view (bug 1491438), the resulting behavior is undesired.

What should be done here? My immediate reason for reporting the bug is because I saw a red attention-grabbing rectangle that wouldn't go away, but I can also see that it might not be intentional that a Private browsing doorhanger can disappear after the appearance of another doorhanger (e.g. extension install).

Comment 2

[Shane Caraveo (:mixedpuppy)]

onDismissed should only be called with user interaction. If you want to change that to always be called, it should pass a flag for whether the user interacted, and for the addon notifications that require user interaction, they should not resolve. So you're still left with the problem.

IIUC appMenu should add a menuitem entry onto the menu when opened, or re-open the panel instead, when the panel has been dismissed in this fashion. But I haven't traced through the code to look at that and why it isn't happening.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:MattN, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Matthew N. [:MattN]]

Shane, can you assign a priority? Should we move this to an extension component since it's the main consumer? The code in question hasn't been tracked in this component before.

Comment 5

[Shane Caraveo (:mixedpuppy)]

I think the component here is correct, but am attaching this to the list of panel issues that affect addon install flow.