159036 - pop-up blocking should use a whitelist of allowed times to open a window rather than a blacklist

Status: RESOLVED DUPLICATE of bug 197919

(SeaMonkey :: UI Design, defect)

Description

[Mike Young]

It has been discussed in numerous bugs (bug 126224, bug 132031 and dups) that
the method we use to determine "unrequested" windows is not sufficient. (Sites
can use onload event handlers in images for example.)

This bug calls for the creation of a "Whitelist" of valid, requested windows.
Instead of devoting man-hours to constantly countering every move a developer
makes to get a pop-up, we simply enumerate what *is* a valid window and keep our
work to a minimum. 

If done properly, this should not result in any significantly higher number of
false positives, and in fact may fix some of the issues at hand currently like
clicking a valid popup-creating link during the page load which is caught as
invalid.

While the actual complete whitelist should undergoe discussion, the following is
my list of "requested" windows:

1. Opened from the interface (in new window, middle click, File > New, Accel-N,
etc.) -- these are already immune and don't need to be worried about.
2. Opened via an onClick, onDblClick, onMouseDown, onMouseUp, onKeyPress,
onKeyDown, onKeyUp, onSubmit?(debatable).
3. Opened via a javascript: URL of a clicked link.
4. Opened via a function called from one of these functions. (anywhere down the
line)

The onSubmit is not necessarily a user-activated event, but is often used as
such. (I would say onFocus too, but the idea of someone *requesting* a popup
window via tabbing into a field seems far-fetched.) The problem is that a
malicious web developer could call a submit() routine on a form with no visible
elements and no href and effectively get around the popup blocking. (This is
similar to the case in bug 152007 -- there an onload calls a submit which
submits to a new 'target' thereby opening a new window... tricky and evil.) 

Rginda posed a question to this list in bug 126224 which I'll answer here to
keep the bugs on-topic.

>> what about |document.location = "javascript:void window.open('foo.html');";|?

I would posit that a javascript: url would only have the rights to open a new
window if originally activated via a user action (click, keypress, etc.) If this
line was present in a function which had been called via a valid event handler
(2) or a javascript: link (3) or a function called from such (4) *then* it would
be valid.

-----------------------

This will require being ale to determine what was the original cause of the
activation of a given javascript function. I am not enough of a javascript guru
to know whether this is possible without (as rginda suggests) a flag which is
kept through the life of the function (and its children) which validates whether
the calling method was on our list. 

The above method would really only work in GlobalWindowImpl::HandleDOMEvent and
therefore would need to be worked out for javascript: URLs. 

Thats it for now. Other issues which may need to be discused (so I don't forget
them down the road...)
1. A named target in a link or form submission -- is it a request? (didn't we
have a pref for this at some point? Should it only be a request if called via a
user action (i.e. stopping bug 152007)
2. Accessibility people may need to look at the list of event handlers. (I added
keyboard handlers for this reason, but there may be others I'm not considering.
-- focus)

Comment 1

[Jason Bassford]

> 1. A named target in a link or form submission
>  -- is it a request? (didn't we have a pref for this
>  at some point? Should it only be a request if called via a 
> user action (i.e. stopping bug 152007)

The question is, is the user aware that this will happen when they submit the
form, etc.?  The site may not inform of the fact that this other thing will
happen, in which case I think it would be unrequested.  But, then again, they
might tell the user in the text of the form or elsewhere on the site, in which
case the user would be perfectly aware of the consequences of submitting the
form, and the window WOULD be requested.

But from a programmatic standpoint, Mozilla can't determine if the user has
become aware of this behaviour or not.  (Even if there is text on the site
describing what will happen, the user may have gone ahead without reading it.)

Therefore, we only have three options as I see it:

1. Allow for gradients of enforcement in the pref where "strict" enforcement
blocks everything like this without question, and "standard" enforcement lets it
through.

2. Pop up a dialogue box in such a case asking if the user wants the window or
not - since Mozilla is unable to determine on its own what to do.

3. Either block all such windows, or allow all such window to be created.

At a more general level, any of the above could also be linked into preferences
on a site by site basis.  (But that shouldn't determine which approach we decide
on.)

Comment 2

[Mitchell Stoltz (not reading bugmail)]

As I'vw said before, rather than everyone filing a bug on the way they think
these things should be handled, we need to come up with a good general strategy,
with usability and a good user experience as top priorities. Let's discuss it in
the newsgroup (n.p.m.security).

Comment 3

[Mike Young]

OK, a thread has been created in n.p.m.security with the title of this bug.

Message-ID: <ahnaft$[e-mail]>

I don't know about the classification of this as an enhancement... There is a
fault with our implementation of "disable unrequested windows" since it doesn't
disable all unrequested windows. Now, granted we can fix those faults/bugs on a
case-by-case basis, but it would probably be more in our best interests if we
fixed this bug instead. (I would hate for the enhancement designation to turn
away developers to the individual bugs....)

Comment 4

[Jonas Jørgensen]

*** Bug 162615 has been marked as a duplicate of this bug. ***

Comment 5

[Jonas Jørgensen]

Setting severity to normal; while pop-up blocking not being based on a whitelist
is not in itself a bug, it makes no sense to have the solution to the bugs in
our current pop-up blocking marked as enhancement.

Comment 6

[Ronald van Kuijk]

Look at http://www.cc-net.or.jp/~piro/xul/_policymanager.html

It makes it possible to do blocking and other stuff based on profiles etc...
Much is already built-in in Mozilla, but this is the ui

Works realy well.

Comment 7

[Ari]

Attachment: a hack to test an approach

The is a hack to test an approach to fixing this bug. Opening new windows is
only allowed if the last event received by GlobalWindowImpl::HandleDOMEvent is
a mouse click, double-click, or something similar. Is this a good way to do it?

Comment 8

[Mats Palmgren (inactive)]

*** Bug 164735 has been marked as a duplicate of this bug. ***

Comment 9

[John A.]

I'm not a developer, but it seems obvious to me that what you need to do is
block all new windows requested by a loading page from the time said page starts
loading to the time it's finished loading.  You've managed to get the stop
button to enable & disable during this period.  It shouldn't be that difficult
to disable & enable all new window requests at the same time.

Just my two cents.

Comment 10

[Mike Young]

The problem with such a "blacklist" method is that you can easily fool it by
coming up with a method we haven't thought of. (Check some of the bugs blocked
by this one for examples.) 

An easy one to get around your suggestion would be to make a popup appear the
first time you moved your mouse in the window.

Another would be to have the popup appear when the SRC of an image was changed
(a script could wait until the page is finished loading and then change the SRC)

Neither of these would be blocked in the current (or I'd venture to say almost
any) blacklist method we choose. In fact, they are already being used to
circumvent our blocking. 

Comment 11

[Sean Harding]

It would also break the correct behavior when someone clicks a link before the
page is finished loading, if that link uses window.open. It's pretty common for
people to click links while the page is loading, especially if the page is
large, their link is slow or the server is slow.

Comment 12

[Don Erway]

For me, the simple way to implement this is "No popups, period.", unless the url
is an address or domain, on a list of "sites I use, which I need popus for."

I find now, I just turn everything off.  Then going to a banking site, or
whatever, where I want/need the popups to work, I click it back on...

Then, typically forget to turn back off, until the next time I get some
offensive popups.

It should work just like cookie blocking/allowing by site.

That is what the whitelist should be.  Just like the whitelist email spam
filtering, by selected good, allowed addresses.

Don

Comment 13

[Rob McMillin]

Regarding Don Erway's comment 12, I respectfully submit this is a poor design
choice.  One might reasonably ask -- how do you know popups are needed to
navigate the site if they're disabled by default?  Tooting my own horn by way of
an example, consider our own site, PriceGrabber.com:

http://www.pricegrabber.com/search_getprod.php/masterid=509684

and observe the "Tech Specifications" link at the upper right.  Clicking on this
creates a new popup window, but the important thing to recall is that *the user
requested this popup* -- not some intrusive ad trying to sell me inferior webcams.

Comment 14

[Matthew Miller]

Rob, as a web user, I see that as a problem with your site. If I wanted
something in a different window (or tab), I'd click the appropriate button to
make it so. 

(It's worth noting that with your current design, there's no easy way to make
the link come up in a tab.)

I realize that you're trying to use this feature for good, but the fact is
popups are mostly used for ill -- and the good you're achieving is slight. I see
it as worth having the option to throw out all sites that use popups, even if
some of them mean no harm. There's plenty of excellent sites which *don't* use
popups, and those that do will learn.

Comment 15

[Rob McMillin]

Re comment 14 -- fine, if you want a new widget that blocks *all* popups, I have
no problem with that, but at least give me as a user the option of

  Block popups:

    o None
    o Only those I don't select
    o All

Forcing only a binary choice for popup blocking is draconian.

Comment 16

[Nahor]

There could be the same kind of interface than for cookies. When a popup want to
show up, Mozilla ask the user what to do (showing as a window/showing as a
tab/not showing) and if you want to remember the setting for this site.

Comment 17

[Matthew Miller]

Nahor -- yeah, that's exactly what I'm envisioning. And Rob, of course.

Comment 18

[Rob McMillin]

Re comment 16, interesting, but I think I'd find it as objectionable in practice
as the "Ask Me" setting for cookies.  But if you want that as an option for
setting up the whitelist, yeah, fine.  Consider the following amendment to my
earlier proposal:

  Accept popups:

    o All
    o Only those I cause by clicking on a link
    o Only those from sites in my whitelist
        x Ask me when a site wants to cause a pop up
    o None

(This makes the choices easier to understand because they're a series of
positive settings.)

Comment 19

[Sander]

Could you people please stop spamming this bug? This is not about blacklists or
whitelists or the like as end-users see it, this is about how to technically
determine what is an "unrequested" window (so we won't be fooled by
onMouseOver's and the like).
Experience has proven that once the amount of non-constructive chatter becomes
too large (yes, I realize I'm not helping here) the chances of seeing a patch
with the bug go down very fast. If you want to reply to this, do so via email...

Comment 20

[Felix Miata]

Practice what you preach pricegrabber. On your page I don't see two different
links, one providing the requested information in the existing window, and
another providing  the requested information in a new window. The link simply
makes an offer, not a choice of how to receive the requested information. Why
don't you try giving the visitor a choice and see how often the choice is same
window. I don't know about others, but the only new windows I ever want opened
are those I explicitly select. Explicitly NEVER means opened by the page simply
from clicking a link, unless the link itself expressly spells out that would be
the result, and not some status bar message. Explicit means I have either used
the context menu or the main menu. Period. It's my PC, not the webmaster's. The
whitelist is an excellent idea. Deny all via prefs. Allow only those expressly
added to the whitelist by the user. Your proposal in comment 18 does look good,
but the definition of popup isn't universally known and should be changed from
popup to unrequested windows. Also, a fifth option should be provided to open
what would otherwise be popups instead in new tabs.

Comment 21

[Sandy]

Clarification of unrequested window issues?

B&H Photo produces the same results as Pricegrabber link (#13) for a link "Why
can't we show you the real price" except it offers right_click menu options to
open link in a new window or tab. But, it doesn't specify the default will be a
pop-up. See below for details. 

Mini-issue: does this difference leave it in or remove it from the category of
"unrequested windows"?
Meta-issue: how can a user control browser behavior desireable to authors that
is undesireable to the user. 

IMHO users would best be served if Mozilla offered a uniform model for all
"distractions" or bandwidth "hogs". It would be similar to normalizing the
setups for cookies and images now in place. A list of these might include
images,(some) plug-ins, pop-ups, Java, Java-script, streaming media, etc. It
would offer right-click control to allow "opt-out/in site" list building plus
Preferences settings based on, for example, a 3X2 matrix of choices of Yes Ask
No seperately for "from originating page" and "other" plus list management for
opt-in and/or opt-out list management.

This scheme would provide a uniform appearance and procedure for the user. It
would allow common file formats for parameter and opt-in/out lists and
significant use of common code.

see http://www.bhphotovideo.com/bh1.sph/<line break>
FrameWork.class?FNC=GetItem__Aindex_html___IC=CAPSG2___SID=F15C3EDB6C0

Tutorials for the technique at
http://www.southwest.com.au/~jfuller/javascript/javascript8.htm#
http://www.oreillynet.com/pub/a/javascript/2001/07/13/javascript_windows.html

Comment 22

[Daniel Veditz [:dveditz]]

*** Bug 177390 has been marked as a duplicate of this bug. ***

Comment 23

[Aman]

Test case:
http://www.ocf.berkeley.edu/~amanb/tmp/popup.html

Comment 24

[Sander]

*** Bug 192484 has been marked as a duplicate of this bug. ***

Comment 25

[guym]

It seems simplest to have an anti-pop-up gradient choice:
1. window.open is always allowed
2. window.open disallowed from onload (or functions called by onload)
3. window.open disallowed from onload and not the result of onMouseOver,
onSubmit, onChange, etc (or functions called by these methods). [perhaps default]
4. window.open only allowed from javascript: link (or function called by the link).
5. window.open never allowed

It seems ridiculous overkill to manage pop-up permissions on a site-by-site basis.

Comment 26

[Jesse Ruderman]

*** Bug 193872 has been marked as a duplicate of this bug. ***

Comment 27

[Mitchell Stoltz (not reading bugmail)]

Over to XP Apps

Comment 28

[Matthew Schultz]

I think my thoughts are the similar as per bug 197919 but it must be easy for
the simple end user to understand.  These two options should cover any other
abusive popup code:

[x] (boolean) Block non mouse click event handlers

[3] (integer) Number of popups allowed open at one time

Comment 29

[Chris Pickett]

Hi.  I am glad you guys want to make a whitelist.

You'll probably find the following URL interesting, if you don't already know
about it:

http://www.popup-blocker.info/testpage/test2.html

The guy has some interesting definitions of what "should" and "should not" cause
a pop-up window, obviously he's trying to promote his pop-up blocking product,
but there are several "should create a pop-up" examples on that page that you
might want to discuss here.

I filed bug 223174 because of it, and I think it's best if this bug 159036
blocks that one.

Comment 30

[Jesse Ruderman]

danm has a fix in bug 197919.

Comment 31

[Jesse Ruderman]

Fixed.

*** This bug has been marked as a duplicate of 197919 ***

Comment 32

[Aarti Kashyap]

My advice goes for an extension change for Adblock Plus.

It has several lists, which are updated on a regular basis and you do not really need to configure or change it more than once or twice.
https://www.corpkart.com/hardware/computers/workstations

Firefox Version

Chrome version