1183212 - Opening customization panel doesn't remove the update's badge from hamburger menu

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[Matteo Ferretti [:zer0] [:matteo]]

Originally, the update's badge were removed once the user opened the PanelUI menu, that contains the actual restart / download update button / notification (see: https://bugzilla.mozilla.org/show_bug.cgi?id=1080406#c29 ).

Currently we have a regression since the update button is an image instead of a character.
It could be easily fix, but considering we want now support multiple badges on menu button (see bug 1180584), we probably have to rethink the user experience we want to deliver.

Comment 1

[Mark Hammond [:markh] [:mhammond]]

Here's my vague idea:

* We leave this regression alone for now and let bug 1180584 land without fixing it, but commit to addressing the new UX we decide on ASAP.

* We change the requirements such that when a "badge" is added to the button, we insist that the same badge icon appears in the popup menu itself - eg, when there is a pending update, the highlighted line in the popup telling you to update also has the badge icon on that line. When there's an FxA authentication error, that line on the popup also shows that badge.

Eg, if there are 2 badges active (ie, *both* a pending update and an FxA auth error) only the pending update badge appears on the button itself, but both "badges" are visible in the popup itself.

This means that the user can immediately see the badge reflected in the popup itself to reinforce what the badge is for, but also see other important badges.

Re "remove badge on click":

* If we reinstate the "drop badge on button click", the same badges *do* remain in the popup itself - this helps reinforce that something important is pending, just not cluttering the button itself.

* However, I personally would prefer something a little smarter - in the popup iself, next to the duplicated badge, we show a [X] icon or similar. If the user clicks on that [X], we then drop the badge from both the button and the popup, and also remove the colored highlighting from the popup.  IOW, a simple click on the button *does not* remove the badge or menu highlight, but instead the user can click on the [X] next to the badge in the menu to remove the badges from both the button and the menu.

This means that if the user uses the button for something unrelated (say, to print a page), they do *not* have the badge disappear. However, they still have the ability to explicitly say "I don't care about this" with an additional click in the popup area.

I wish I could mock this up and I'm sure the above isn't completely clear - please let me know if I'm not making sense.

Comment 2

[Stephen Horlander [:shorlander]]

I think I agree with everything Mark said in Comment 1 except:

> * However, I personally would prefer something a little smarter - in the
> popup iself, next to the duplicated badge, we show a [X] icon or similar. If
> the user clicks on that [X], we then drop the badge from both the button and
> the popup, and also remove the colored highlighting from the popup.  IOW, a
> simple click on the button *does not* remove the badge or menu highlight,
> but instead the user can click on the [X] next to the badge in the menu to
> remove the badges from both the button and the menu.

I don't think we should ever have people micro manage these badges in this context. If we were ever to do something a little smart about collecting browser level notifications then maybe. But not on something like this that should largely be transient.

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

This appears to be fixed by the work in bug 1186521.