Closed
Bug 159036
Opened 23 years ago
Closed 21 years ago
pop-up blocking should use a whitelist of allowed times to open a window rather than a blacklist
Categories
(SeaMonkey :: UI Design, defect)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 197919
Future
People
(Reporter: mozilla, Assigned: danm.moz)
References
Details
(Keywords: helpwanted)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
> 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•23 years ago
|
||
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).
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Reporter | ||
Comment 3•23 years ago
|
||
OK, a thread has been created in n.p.m.security with the title of this bug. Message-ID: <ahnaft$aqn4@ripley.netscape.com> 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....)
Keywords: mozilla1.2
Comment 5•22 years ago
|
||
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.
Severity: enhancement → normal
Keywords: helpwanted
Comment 6•22 years ago
|
||
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.
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?
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.
Reporter | ||
Comment 10•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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 18•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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.
Updated•22 years ago
|
Summary: Strengthen Disable Open Unrequested Windows via whitelist → pop-up blocking should use a whitelist of allowed times to open a window rather than a blacklist
Comment 21•22 years ago
|
||
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 25•22 years ago
|
||
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.
Updated•22 years ago
|
Keywords: mozilla1.2
Comment 27•22 years ago
|
||
Over to XP Apps
Assignee: mstoltz → shliang
Status: ASSIGNED → NEW
Component: Security: CAPS → XP Apps
Comment 28•22 years ago
|
||
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•21 years ago
|
||
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 31•21 years ago
|
||
Fixed. *** This bug has been marked as a duplicate of 197919 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Blocks: pop-up-arms-race
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 32•5 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•