User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031201 Firebird/0.7+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031201 Firebird/0.7+ This URL demonstrates a popup blocker evasion system which uses the clicking of any link on the page as a trigger to open a popup. This could probably be dealth with by preventing popup windows from being created by scripts that also continue to open a link (but this might night be the designed behavior). This one is tricky, but it would be wise to handle if possible. Reproducible: Always Steps to Reproduce: 1. Go to the URL with Firebird 2. Note that an active blocker was detected. 3. Click a link and get a free ad.

Kevin, thanks for being on the lookout for sites that defeat popup blocking. There are several known vulnerabilities and no doubt some more that aren't known. We'd like at least to have them enumerated in bugzilla. But this particular case really isn't an example. For starters, I'd be embarrassed to publish the clumsy sample script they tout at adoutput.com. (That said, they deserve credit for (presumably) finding something that works on all browsers. But the structure of the code tells me it was built by random accretion of test cases and the result is actually funny, in a geeky kind of way. I'd lay money that even they don't understand how it really works.) Ahem. But more importantly, what they're doing, it's not popups at all. It's instructions for building a website that opens a new window every time the visitor clicks a link on the site. Any moron can do that. There's no trick to it. adoutput's code saves the website author the trouble of typing a secondary clickhandler into every link, is all. By definition, popup windows are those that open unexpectedly, in the absence of any user action. It's a perfectly valid action to open a new window in response to the user clicking a link. We don't want to disable that functionality. I suppose some users would appreciate it if content script were under no circumstances ever able to open a new window. Actually I find that kind of appealing, myself. But if we want to open that door, that would be an enhancement request bug. In the meantime, barring actual defeat of the popup blocking code, if the visitor to such a site has popups blocked, new windows can be opened but only in response to clicking a link. The new windows can't themselves be used to spawn a popup cascade, so they can be closed without repercussions. The new windows can't really be stopped, since it's just code running directly in a clickhandler. Many legitimate sites would break were that disabled. But at least minimal damage is done.

The same problem rears up again in bug 230500. So I'm expounding on my previous comment with the idea that we may have to do something about this. Restating, this script (and the one in 230500) is equivalent to simply writing a web page with click handlers that open popups. If we hamstring script in the name of popup protection, people will simply begin hardcoding these clickhandlers. Worse, we become incompatible with legitimate websites. It's out of the question. CNN pages, for instance, are swimming with legitimate links that read <a href="javascript:LaunchVideo(...)"> or <a href="javascript:CNN_openPopup(...)">. They could just as easily have been written using a click handler. And though services like adoutput.com make it easy for naive webmasters to strew popup click handlers throughout their site, it's not much more difficult to hardcode it, without script. Or to script it server-side. These exploits will follow if we somehow find a way to suppress this one. Still, gotta admit, new windows I didn't ask for are hazardous to my blood pressure. In the realm of off-by-default, geek-only features, the only solution I can think of is to add another level to popup blocking: ( ) block unrequested popup windows (*) block all freaking new windows from user script, every one and tie it in with some sort of extemporaneous override, similar to bug 222763. Also helpful would be the morning after override, bug 198846 / bug 176564. (Though 222763 requests the opposite capability, it's the same idea.)

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

Also see bug 197919, which suggests Mozilla make click handlers subject to popup protection. That too would solve this problem, for now.

The click handler pseudo-popup practice is becoming more common (see bug 230500) and it is annoying, I agree. I'm reversing my previous decision to invalidate this bug. Again, we can't simply stop opening windows in click handlers by fiat. That wouldn't be playing nice. But perhaps we could make it an advanced preference. Note that bug 197919 is a superset of this problem. I'm toying with a fix for that one, so there's hope for both.

Update: it looks like the patch to bug 197919 will be checked in. It suppresses popup windows in (among other things) click handlers. Though it's a rather flawed solution to the problem in this bug, I can't think of a better one. See bug 197919 comment 32 for a small study of the benefits and injuries of that solution.

"In the realm of off-by-default, geek-only features, the only solution I can think of is to add another level to popup blocking: ( ) block unrequested popup windows (*) block all freaking new windows from user script, every one" There are yet other ways to get around this (simply placing a layer over the webpage with some javascript that allows you to hide it) or hovering flash ads. These have the same effect and are equally as annoying. The only thing I could think of is content controls that allow you to block specific scripts and allow the user to block any event or javascript function for sites that they want (I believe there is a bug for security profiles somewhere that would allow you to use certain settings for one site, and other settings for other sites) - this would allow you to block onClick events on a page-by-page basis. This is along with the general content blocking (also another bug which I am too lazy to look up), the ability to hide specific div's, and you are set until they come up with some other trick (and they will). There is also the anti popup blocker scripts (there is also a bug about that) which force you to turn off your popup blocker unless you want the page to be blocked. Basically my point is that there will be no good solution for your average every-day users, and you would have to employ quite a bit for the ultra-geeks to be able to block them.

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

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

Just as a proposal to a resolution, maybe an option to stop this type of activity could be made. The user could add a specific page to his/her list that would not allow this type of activity to occur on said specific page, hence eliminating a problem with legitimate pages as pointed out. My guess is most people who find this occurence find it in a page they visit frequently and they would most likely add it to their own personal list of blocked sites.

www.spacedaily.com has some nasty popup blocking avoidance. When using FireFox they popup a box that looks like an official FireFox dialog "wizard".

Let's try to keep focused, please. Comment 11 has nothing to do with this bug.

Here is another sample that evades Firefox (taken from AquaBid.com - two pop-ups appear on page load): <!-- TF 728x90 JScript VAR code --> <center><script language=javascript><!-- document.write('<scr'+'ipt language=javascript src="http://a.tribalfusion.com/j.ad?site=AquaBidcom&adSpace=ROS&size=728x90&type=var&requestID='+((new Date()).getTime() % 2147483648) + Math.random()+'"></scr'+'ipt>'); //--> </script> <noscript> <a href="http://a.tribalfusion.com/i.click?site=AquaBidcom&adSpace=ROS&size=728x90&requestID=1538837377" target=_blank> <img src="http://a.tribalfusion.com/i.ad?site=AquaBidcom&adSpace=ROS&size=728x90&requestID=1538837377" width=728 height=90 border=0 alt="Click Here"></a> </noscript> </center> <!-- TF 728x90 JScript VAR code --> <!-- FASTCLICK.COM POP-UNDER CODE v1.8 for aquabid.com (12 hour) --> <script language="javascript"><!-- var dc=document; var date_ob=new Date(); dc.cookie='h2=o; path=/;';var bust=date_ob.getSeconds(); if(dc.cookie.indexOf('e=llo') <= 0 && dc.cookie.indexOf('2=o') > 0){ dc.write('<scr'+'ipt language="javascript" src="http://media.fastclick.net'); dc.write('/w/pop.cgi?sid=20257&m=2&tp=2&v=1.8&c='+bust+'"></scr'+'ipt>'); date_ob.setTime(date_ob.getTime()+43200000); dc.cookie='he=llo; path=/; expires='+ date_ob.toGMTString();} // --> </script> <!-- FASTCLICK.COM POP-UNDER CODE v1.8 for aquabid.com -->

As I posted here [https://bugzilla.mozilla.org/show_bug.cgi?id=253831#c296] www.dilbert.com also opens a pop-up window from a.tribalfusion.com, no matter what blocking settings I have for pop-ups and JavaScript. This pop-up window only appears on the first time I enter the site for a given Firefox session (as long as I don't restart the browser, successive attempts on www.dilbert.com don't trigger the pop-up window).

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

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

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

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

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

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

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

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

I'd like to give another example of a site that can bypass the pop-up blocker. http://www.comics.com/comics/janesworld/ causes a pop-up. The "prevented a popup" strip appears, but I also get a separate window for http://a.tribalfusion.com/p.media/RQILMIMKFJEXNTTPOIYNPGIHTFPXPISVIEJFIMVHJFCEKBSQNERKLOGWSFMLPIIKKHRCSLQSLJKSPTK/581936/pop.html which contains a single (stupid, irritating, childish, annoying) flash animation and a 1x1 gif which I imagine is for tracking purposes.

Not certain if this is the same thing, but I suspect so. The top of the bug report should include some way to test or assess it. However, this bug report seemed to be the best candidate I could find. I can definitely say that my Firefox is set to block popups on all of my computers, but this ad.yieldmanager.com website is managing to trigger popups in some way. Below is the source of one of the typical new browser windows that is popped up, but I have not been able to identify how it is being done in the source of the webpages where it is triggered. It is not consistent every time, but http://shanenj.tripod.com/search.html is a page that I visit that frequently shows the misbehavior. There is a delay before the popup appears, but I didn't think it was related to a link, but rather to a delay, a mouseover event, or possibly to form submission. Or perhaps they are mixing it up to try to hide the triggers? I can confirm seeing on both Ubuntu Linux and Windows XP, and in Firefox 1.5 and 2. <html><head><title>New offer!</title></head><body style="margin-left: 0%; margin-right: 0%; margin-top: 0%; margin-bottom: 0%"><script type="text/javascript">if (window.rm_crex_data) {rm_crex_data.push(240084);} </script><a target="_blank" href="http://ad.yieldmanager.com/click,YSAAAAlTAgDUqQMAvHABAAAA.AEAAP8A.wD..wAIAAIi.AEAUzABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH6MvkUAAAAA,,http%3A%2F%2Fshanenj%2Etripod%2Ecom%2Fsearch0%2Ehtml,"><img border="0" alt=""height="300" width="720" src="http://content.yieldmanager.edgesuite.net/atoms/20/6c/206c17fefe4aa4f94cad5f65b8d39799.gif"></a></body></html>

Still not certain if I'm trying to report the same thing as this bug, but I studied it some more, and right now I think the behavior I'm trying to report is linked to *ANY* click in the webpage as a trigger for the should-be-blocked popup window. Watching closely, it appears that the aggressive scum at yieldmanager.com are somehow downloading and storing the ad somewhere during the preparation of the original page (making that page much more slow, too), and then triggering it. You'd think they'd have learned from the bankruptcy fate of those bastards at X10. I feel like the real solution is to organize boycotts of any company that advertises too aggressively...

Having read many more of the comments in this thread, I feel like I should retract the previous comment as too hasty--it is clear that I am talking about the same thing. What I want to do as the solution is have a convenient option to mark sites like yieldmanager.com as 127.0.0.1, thereby consigning them to limbo.

Having read all the comments in this bug report...and see no action... I would just like to state that IE7 handles this problem without allowing the popup window to occur. So it is possible.

I'll try to fix this bug.