Closed Bug 333531 Opened 18 years ago Closed 2 years ago

Add Preference to Restore Pop up Blocker in Status Bar

Categories

(Camino Graveyard :: Annoyance Blocking, enhancement, P3)

All
macOS
enhancement

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: froodian, Unassigned)

References

Details

Attachments

(3 files)

There's been a lot of talk over the new inline pop up blocker.  The opinions seem to be pretty strongly split between people who find it just as intrusive as the pop ups they wanted to block in the first place, and the people who never even realized pop ups were being blocked previously.  Given this split sentiment, I propose (as was originally brought up both on the forums http://forums.mozillazine.org/viewtopic.php?t=396209 and in Bug 331406) that we add a pref to put the blocker back in the status bar.  As Bug 331406 Comment #3 says, 

"Ship it with the current behaviour, but let people hide the notification if
they want. That's the whole point of the status bar, after all, and if people
hide notifications and hide the status bar, tough cookies."

Despite the evilness of maintaining two sepereate UI schemes for a single purpose, I believe that this is the best course of action, and will give the most people what they want/need from Camino.
is there a reason why this is still unconfirmed?
I've been working on some UI ideas to add this to the inline bar (along the lines of the "don't show again" boxes on sheets) along with better options for bug 331194; once I'm no longer playing host, I'll try and get some mockups up.

(In reply to comment #1)
> is there a reason why this is still unconfirmed?

We're waiting on MOA for this proposed solution.
Just my two cents as a user, but with this version (2006041100) and the last nightly I had downloaded, it seems just as annoying as a pop-up itself to get a semi-pop-up that says a pop-up was blocked. A feature to say "don't show again" would be the best solution, I'd think. This has been one of those times (and there are many of these times) when I feel like I missed a preference somewhere, but everytime I visit nytimes.com I get the message, over and over. I appreciate the pop-ups are blocked, but being nagged about them is why I want to block them in the first place. 
Ok, I went at this with an eye to providing a solution that will also accomodate the changes that are coming in bug 331194.

Basically, there are 6 options possible for acting on any given popup/notification in the current system (not all of them are currently implemented, of course, though some are coming via bug 331194):

* "Unblock" the pop-up (i.e., add the domain to the pop-up exceptions (white)list without showing the pop-up).
* "Configure…" pop-up blocking (turn it on/off in the prefs, and access the exceptions list)
* Close the notification and do nothing
---- above are currently implemented ----
* Show the blocked pop-up
* Show the blocked pop-up and add the domain to the exceptions list
* Show the pop-up blocked notification (and options) in the status bar like old times

In bug 331194 pink says what everyone wants to do is whitelist the site for pop-ups.  If people want to do that, then they also want to see the pop-up (without reloading the page), so "Show the blocked pop-up and whitelist the site" should be exposed.

In bug 331194 I argued that lots of people don't want to whitelist a site without making sure they really want the pop-up (i.e., without seeing it), so there should be a way to show a pop-up without whitelisting it first.  If you accept this argument, then "Show" should be exposed. 

This bug plus feedback indicates that an option to switch the notification to the status bar (perhaps a toggle) should be exposed.

The inline bar needs to be closeable, so it needs an X (the status bar icon went away with a new pageload, so this option is not needed there)

Configure… allows access to all the other options (adding/deleting from the whitelist, disabling pop-up blocking entirely), so it can be a proxy for the less-used options and still keep the UI of the inline bar and the status bar icon menu clean).

With that in mind, I have two mockups of how the bar could be redone.  Note that in each of these mockups, I have redefined "Unblock" to cover the "whitelist the domain and show the pop-up" option above, and "Show" simply shows the pop-up.
OS: Mac OS X 10.2 → Mac OS X 10.3
Option 1 provides an additional button, "Show" (to show the blocked pop-up; again, "Unblock" now means "whitelist the domain and show the pop-up"), and a checkbox that will toggle the "show the blocked pop-up notification" to the status bar (the status bar icon's menu should have a corresponding item to allow toggling back to the inline bar--or that pref should be exposed in the prefs, which I think is overkill and would clutter that prefPane).

Text of the checkbox label is subject to refinement, of course :)
Attached image Option 2 - Action menu
Option 2 uses the "Action menu" concept that appears elsewhere in Camino.  

This option allows the inline bar to remain unclutted and allows the items describing the actions to be more specific and more clear to the user, e.g., "'unblock' foo domain" and "show pop-up with url foo/bar".

The "show in status bar" item is a toggle; you select it, it gets a checkmark, and the next time you encounter a pop-up, the notification shows up in the status bar.  You select it again, the checkmark vanishes, and the inline bar is back.

The other plus of this implementation, at least on the surface, is that we're using the exact same menu, menu items, etc., in both the inline bar and the status bar--less code to maintain, I hope.  

Again, "unblock" here will mean "whitelist the domain and show the pop-up".  

At the moment, this mockup is my preferred option.  Things to clarify yet: which menu items make the inline bar vanish (the status bar icon only vanishes on a pageload).
(In reply to comment #4)
> This bug plus feedback indicates that an option to switch the notification to
> the status bar (perhaps a toggle) should be exposed.

Stuart and I talked about this on irc tonight.  There are two issues which argue for placing this (the "where does Camino show notification" pref) in the prefPane:
1) no one changes the "where" pref each time they see a pop-up
2) if someone sets the "where" pref to the status bar, then later hides the status bar (when it becomes hideable), how does the user change the "where" pref?

I'm not opposed to putting the "where" pref in the prefPane (and issue 2 is a solid reason for doing so), but at the same time, I don't think users should have to (know to) go to the prefs to toggle the "where" pref.  (Having it only in the prefs seems like feedback-fodder--and bug- and forum- and mailing-list-fodder, too--which exposing the "where" pref in the inline bar would head off.)
> (Having it only
> in the prefs seems like feedback-fodder--and bug- and forum- and
> mailing-list-fodder, too--which exposing the "where" pref in the inline bar
> would head off.)

If it were in the prefs, the "where" pref could also be exposed in the initial sheet that comes up at the first popup.  Right now it does 

--------------------------------------------------------------------------
This web site is attempting to open an unrequested popup window.  Camino can automatically prevent Web sites from opening popup advertisements.  Click OK to prevent all unrequested popups (including this one) from opening.
                                         --------     --------
                                        | Cancel |   |   OK   |
                                         --------     --------
--------------------------------------------------------------------------

We could do something like:

--------------------------------------------------------------------------
This web site is attempting to open an unrequested popup window.  Would you like Camino to automatically prevent Web sites from opening popup advertisements like this one?
              -------------      ---------------------   ---------------------
             | Don't Block |    | Block in Status Bar | | Block in Inline Bar |
              -------------      ---------------------   ---------------------
--------------------------------------------------------------------------

with "Block in Inline Bar" given the focus.
This would be good because
a) It complies better with the HIG than what we currently have, by replacing confusing "OK"/"Cancel" dialog sheets with explicit ones.
b) It keeps the new, more "novice-friendly" blocker as default, but
c) It allows users to easily change the pref without searching for it
d) It doesn't introduce any new sheets/annoying UI

Obviously, the text specifics are subject to refinement.
(We should really not keep bugs in the unconfirmed state for this long. Note that many people won't see bugmail coming from an unconfirmed bug.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just to keep everyone here posted, we got approval from Pinkerton today for a user pref (in Web Features) to allow the user to switch from the inline bar back to the old status bar notification.

Note, however, that the old code was really hacky, and when this gets fixed, it will be fixed "right" (no more "hogging a spot in the status bar when not present", among other things), so don't expect the option to appear immediately.
Priority: -- → P2
Target Milestone: --- → Camino1.1
I dislike the idea of having 2 UIs for the same thing, so I have an alternative idea:

First step is to generalize the popup blocker into notifying about other things as well, for example denied cookies (bug 322199).

The next step is to add UI where you can choose which things you want to be notified of, with checkboxes.

That way, those who are annoyed by popup blocked notifications can turn that off. We'll also have one place to notify about things that are important. Other notifications that we deem important enough can easily be added.
And what about people who want to be notified, want UI to unblock specific sites (via whitelist or just the once), but don't want the obtrusive blocker?

Plus, if every potential notification has a "show in obtrusive blocker or don't show at all" pref, the prefs window is going to fill up pretty quick.
*** Bug 344158 has been marked as a duplicate of this bug. ***
Component: Preferences → Annoyance Blocking
QA Contact: preferences → annoyance.blocking
Taking, will fix after RSS.
Status: NEW → ASSIGNED
Assignee: mikepinkerton → nick.kreeger
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
I would I like the idea of intially seeing a pop-up message at the top of the page, but thereafter, having the option to see pop-up blocked notifications (along with RSS) in the status bar. This is an icon I used in my own Camino theme, instead of the old 'splat' icon.
My big problem with the inline notification is it now stands is that it's harder to get rid of the notification than it would be to CMD-W away an actual pop-up. There are simple two ways of mitigating this:

1.) Make the inline notification respond to the keyboard. I propose that typing "X" should make the notification go away.

2.) Increase the size of the close widget for the notification. As it stands now, the "X" you click to get rid of the notification is smaller (and thus harder to hit) than the standard X for closing an application. (Also, it's on the wrong side, but whatever.) I propose that clicking any part of the notification except for the "Unblock" and "Configure" buttons should make it go away.

My 2¢.
nick, any progress on this?
Not gonna make 1.1 without a patch. Pushing to 1.2 for now.
Flags: camino1.1? → camino1.1-
Target Milestone: Camino1.1 → Camino1.2
Blocks: 333284
Setting priority per 1.6 roadmap.
Priority: P2 → P3
Nick, is this still something you have time to work on? If not, can you re-assign to nobody?
Target Milestone: Camino1.6 → ---
Assignee: nick.kreeger → nobody
Status: ASSIGNED → NEW
Hardware: Macintosh → All
Does anyone still hate the popup blocker bar enough to move the notification back into the status bar, especially now that the tab chain is fixed and you can dismiss this bar with the keyboard?
I voted for this, but I haven't used Camino in years, so I no longer care.
The main benefit to still doing something like this is that if you've set a site to "Never Allow", you can still see in the status bar that something is blocked in case you need to allow it on a case-by-case basis (switched to using legitimate pop-ups, uses a mix of legitimate and spammy pop-ups, etc.), but it's not in-your-face all the time otherwise.

This bug lies at rest in the graveyard.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: