588317 - Convert popup blocked bar and icon to a location bar lucky charm

Status: NEW

(Firefox :: General, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

While we are converting nearly all of our notification bars to doorhanger panels, pop-up blocking (and other forms of content blocking) creating a unique case.  Doorhangers panels are designed to be considerably louder than notification bars (but also easy to quickly dismiss).  And as such, showing essentially a popup notification to indicate that we have blocked a popup notification, is perhaps too ironic to actually implement.

One approach (which this bug advocates for) is to place a small icon on the right side of the location bar to indicate that something has been blocked, but otherwise remain silent.  In the case of pop-ups, this could have the exact same functionality as the icon we have previously placed in the status bar (list of popups to show, options).  This would match Chrome's current approach to pop-up blocking.

The downside is that some users are going to miss the notification, since it is smaller and less obtrusive, and might switch browsers if they feel that a certain site does not work with Firefox (if we are blocking pop-up windows that they actually need to access.  To address this we could go back and add a doorhanger notification off of this icon placed in the location bar (however this also brings us back to the irony of displaying a pop-up to indicate that we blocked one).

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Mockup of proposed functionality

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

This is one of the high profile notifications, so requesting blocking on transitioning it (similar to password manager and geolocation).

Comment 3

[Ian Pottinger]

The "Don't show info messages when pop-ups are blocked" could be converted into a checkbox that prevents the doorhangers panels from automatically appearing. The first time a pop-up is blocked and the doorhanger is shown, the checkbox can be defaulted to checked so that without any user action the doorhanger will only appear once.

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

Yeah, the classic solution to these types of problems.  However the freshness of the Firefox profile isn't really indicative of the freshness of the user (a new user could start to access a computer with Firefox already on it, or an existing user could get a new machine).  These types of first run pref-off notifications can get really annoying and I'm not convinced they really solve anything.  You have to get into the section of the venn diagram that has new users with brand new computers, which I think might actually be a boundary case.

Comment 5

[Alex Faaborg [:faaborg] (Firefox UX)]

I think we should move forward with a single icon notification for now.  We already have some logic for determining if the pop-up was the result of a user action, so the majority of these pop-ups should actually fly under the user's radar.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

This is where I start to hate myself; definitely, supremely, absurdly wanted. Should be an easy patch, too. Not blocking, as the notification is already tab-modal.

(see above about hating self)

(wantedwantedewantedwanted)

Comment 7

[StyleThing]

Should we also convert a persona-applying bar into a doorhanger?
Sorry for bothering, but i din't found a bug for that. Should i file it?

Comment 8

[Alex Faaborg [:faaborg] (Firefox UX)]

>Should we also convert a persona-applying bar into a doorhanger?

The personas extension should use the add-on bar (as opposed to being placed anywhere in the navigation toolbar).  Since it uses sub-menus it might not be a good candidate for an arrowpanel unless it has more significant UI changes.

Comment 9

[Ed Lee :Mardak]

Any particular reason to have the icon on the right side instead of the left side where other popup notifications show up? Popup notifications can add icons to the location bar that default to not shown but still show the popup when clicked. ("dismissed" option added by bug 572967)

Comment 10

[Alex Faaborg [:faaborg] (Firefox UX)]

Right side = unimportant (bookmarks, popups, maybe plugin blocked and font size changed)

Left side = important (personal information like passwords, geo-location, account manager, security related questions associated with the site identity block).

Also items on the left side can produce a panel notification, while icons on the right should not (since they are by definition not important).

Comment 12

[Justin Dolske [:Dolske]]

Marking blocking final+. I think in comment 6 beltzner was blocking- as a general statement on if we would block on improving the popup-blocker experience.

However, fryn points out that we currently are in a broken state, where users who have disabled the "popup blocked" notification bar (via its checkbox) no longer have any UI indication that a popup was blocked, or ability to open those popups... The icon was in the status bar, and the status bar is gone now.

Thankfully, doesn't sound like this should be a large or complex fix.

Comment 13

[:Margaret Leibovic]

Attachment: WIP patch

This affects a bunch of tests, so I will also need to update those, but this patch adds the location bar lucky charm and gets rid of the notification bar.

Comment 14

[Frank Yan (:fryn)]

Comment on attachment 496665 [details] [diff] [review]
WIP patch

Since the lucky charm is now the default UI for popup blocking, making it what users will see the first time a popup is blocked without explanation, we should change the pageReportIcon.tooltip entity from "Change pop-up blocking settings for this web site" to something that explains why the icon appeared, e.g. "A popup was blocked on this page". Unfortunately, this is yet another string change.

> +  onReportButtonClick: function (aEvent)
> +  {
> +    if (!this._reportButton)
> +      this._reportButton = document.getElementById("page-report-button");

onReportButtonClick needs to include something like:

    if (aEvent.button != 0)
      return;

to prevent the menu from showing on right-click, since we already show the toolbar context menu.

And, as you mentioned, we should update those tests.

Comment 15

[Dão Gottwald [:dao]]

(In reply to comment #14)
> Since the lucky charm is now the default UI for popup blocking, making it what
> users will see the first time a popup is blocked without explanation, we should
> change the pageReportIcon.tooltip entity from "Change pop-up blocking settings
> for this web site" to something that explains why the icon appeared, e.g. "A
> popup was blocked on this page".

I don't think this is really sufficient to communicate to the user what's going on. It seems to assume that the user even notices the icon. By that logic we wouldn't have had the notification bar in the first place but just the status bar icon.

Comment 16

[:Margaret Leibovic]

(In reply to comment #14)
> Comment on attachment 496665 [details] [diff] [review]
> WIP patch
> 
> Since the lucky charm is now the default UI for popup blocking, making it what
> users will see the first time a popup is blocked without explanation, we should
> change the pageReportIcon.tooltip entity from "Change pop-up blocking settings
> for this web site" to something that explains why the icon appeared, e.g. "A
> popup was blocked on this page". Unfortunately, this is yet another string
> change.

We could use popupWarning and popupWarningMultiple, and just set the tooltip in onUpdatePageReport.

Comment 17

[Alex Faaborg [:faaborg] (Firefox UX)]

>I don't think this is really sufficient to communicate to the user what's going
>on. It seems to assume that the user even notices the icon.

yeah, that is definitely a concern. We aren't assuming that the user is necessarily going to notice the icon.  If we move forward with this approach we need to be ok with the fact that some users are going to miss it, and they will put pressure on web sites to stop designing around pop-up windows.  The trade off here is deciding if we want to pop something up (notification bar, arrowpanel) in response to suppressing a pop-up or not.  If we create an interface that is overly noticeable, we risk being as annoying as the thing we are trying to suppress.

Comment 18

[Dão Gottwald [:dao]]

(In reply to comment #17)
> yeah, that is definitely a concern. We aren't assuming that the user is
> necessarily going to notice the icon.  If we move forward with this approach we
> need to be ok with the fact that some users are going to miss it, and they will
> put pressure on web sites to stop designing around pop-up windows.

This needs to be discussed with a wider audience. And it's not a project we should be willing to start with one of the last betas.

(In reply to comment #12)
> However, fryn points out that we currently are in a broken state, where users
> who have disabled the "popup blocked" notification bar (via its checkbox) no
> longer have any UI indication that a popup was blocked, or ability to open
> those popups... The icon was in the status bar, and the status bar is gone now.

Filed bug 618437 on this.

Comment 19

[Alex Faaborg [:faaborg] (Firefox UX)]

>This needs to be discussed with a wider audience. And it's not a project we
>should be willing to start with one of the last betas.

fwiw this has been discussed at length in a number of different UX meetings.  Outside of the extent to which we need to get buy in from our broader community and other teams before we can make any change to the user interface, I think we've otherwise fully explored all of the various aspects of this decision.

Comment 20

[Dão Gottwald [:dao]]

The point is that popups are a widely (and sometimes legitimately) used web feature. Whether that should be supported in the future may be discussed at length in Firefox UX team meetings, but the discussion shouldn't end there.

Comment 21

[Dão Gottwald [:dao]]

Comment on attachment 496665 [details] [diff] [review]
WIP patch

Even if the icon ends up being the way to go, this patch seems to lack keyboard and screen reader access.

Comment 22

[:Margaret Leibovic]

I uploaded a lucky charm only patch to bug 618437, so that we can at least add the icon while the idea of removing the notification bar is still up for debate.

Comment 23

[Paul [pwd]]

I have a couple concerns.

Weren't we trying desperately to remove clutter/content/coloured objects from the awesome bar, particularly the right side?

How often does a users eyes leave the content area unless specifically looking for something outside of it?

A better proposal for me, would be overlaying the favicon with a doorhanger type notification protruding in to the content area. It would be the best of both worlds for now and then in a following release we can crusade for less pop-up window based design.

Comment 24

[:Margaret Leibovic]

This bug needs some UX input before it can move forward, but it looks like it may just be a WONTFIX.

Comment 25

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

The severity field for this bug is relatively low, S3. However, the bug has 15 votes.
:mossop, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 26

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.