this site will open unrequested windows when box in scripts and plugins is unchecked and popups rejected. I am using the mozilla-win32-1.2b version.

Changing OS to all, noticing bug under Linux. Seems to be Macromedia Flash Applet causing the windows [onLoad open window] Confirming. The component sure isn't security, so I'll set it as Plug-ins for now. If anybody knows where REALLY to put it, put it there.

Current popup blocking only blocks windows while the page is loading, the flash content loaded and started opening windows long after the page itself had finished loading. This is probably a duplicate of some of the RFE's about how to improve popup blockings, but meanwhile I'll try to make the summary more specific/accurate

wouldn't it also depend on how the plug-in is designed?

reassign

Came across a good one today: (WARNING: DO NOT CLICK ON LINK IF YOU DO NOT WANT TO KILL YOUR BROWSER) http://www.geocities.com/xfuctxupx This flash applet repeatedly pops open windows and basically kills any browser that opens it. Enabling pop-up blocking doesn't help anything. -> added keyword 'shockwave'

This is the antithesis of bug 189237. Gerv

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

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

Updated to a URL that exists. Mouse over the boxes to get a popup.

This page loads "hi-rez.html" so it is a "DOM Events" bug and not a "Plug-ins" bug. In fact this is a duplicate of bug 212460. *** This bug has been marked as a duplicate of 212460 ***

Um. That bug is about an event not having some info. This bug is about popups not being prevented. Reopening -- the two have nothing to do with each other.

"That bug is about an event not having some info." Right, that's exactly what this bug is about. Just do some debugging and you'll find out :-)

Ok, I replaced "hi-rez.html" with "http://www.pirates.bethsoft.com/flash/hi-rez.html" and now the popup blocker works. So this *is* a duplicate of that bug.

Clue me in. Any time someone says "do some debugging" with a smiley I'm suitably extra careful. But I still don't get it. I'm with Boris (comment 11). My debugger and I see the plugin synthesizing a click event, which is handled by the normal webshell's click handler, which has no clue the event is coming from the plugin. The popup code is completely fooled and I can see no connection between this and whether the URL is relative. To fix this, we could potentially track the source of a link-click event, and subject ones that don't come from a legitimate user click to popup scrutiny. But in the more general case, plugins can run any script on the webpage. Maybe if we walked all the way up the script stack, looking for plugins...

"My debugger and I see the plugin synthesizing a click event" Well, what click event are you talking about? That site (see URL) simply opens a new window, when I visit that site with mozilla. You don't need a single click to trigger this bug so we're obviously talking about different things.

Oh, 'synthesizing a click event' Maybe I need to debug my code again, to see what is going on...

I looked again and this is what I see: view-source:http://www.pirates.bethsoft.com/flash/fbplus.html <script LANGUAGE="JavaScript"> var newwin; function launchwin(winurl,winname,winfeatures) { newwin = window.open(winurl,winname,winfeatures) } </SCRIPT> And this is what opens that new window: javascript: launchwin('hi-rez.html', 'zenimaxFlash', 'toolbar=no,location=no,directories=no,menubar=no,scrollbars=no,resizable=no,width=680,height=500,left=150, top=200,screenX=150,screenY=200'); So all you have to do is to change 'hi-rez.html' into a full path and the popup blocker works just fine. Same as that other bug. Same bug ;)

I still don't get it. But we'll know soon enough: a fix for bug 212460 was just checked in.

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

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

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

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

Johnny, this seems to be increasingly common. Any chance you can dig into it and see if there's something we can do in our pop-up blocking to cover this tactic?

Anyone know how these popups are opened from flash? If they're opened using javascript: URLs or by loading URLs into a targeted window there's probably something we can do, anyone know for sure?

The vipernetworks page from bug 249555 just does: getURL("JavaScript:promo(\'kickoff.htm\',\'Promo\',\'450\',\'370\',\'scrollbars=no\')"); Which would seem to be fixed by bug 212460 I still get a popup in Firefox 0.9.1, did that patch make it into Firefox?

Danm, interested in hacking something up here? We'd need to inform the global window code that a plugin is loading a JS URL and that window.open() calls from it should be prevented etc. But then there's of course cases where we'd want plugins to be able to open windows, do we need a separate pref here? Or something else?

Another example of a Flash popup that occurs when the page is first loaded is here: http://www.bathandbodyworks.com/index.jsp?navid=0.0.0.4.0

Could it be possible to check if the mouse was over the object when the popup was opened, and then block it if it was not? Although this does not fully solve the problem, it could offer some protection if the flash doesn't cover the page. Would this be doable, or would this just be a waste of effort or impossible? Another thing, if you can check to see if an object is opening the window, maybe a pref for "Allow obejcts to open windows" can be added.

Internet Explorer 6.0 SP2 (available in Windows XP SP2) now blocks Flash-initiated popup windows, according to this: http://www.microsoft.com/uk/windowsxp/sp2/what-it-means.mspx#XSLTsection124121120120

Should now be fixed by bug 258487, see bug 258487 comment 4 for details. Please test it with new builds.

Using this UA: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040917 Firefox/0.10 I'm still getting Flash popups from Bath and Body Works: http://www.bathandbodyworks.com/index.jsp?navid=0.0.0.4.0

Oh, there's now a pref one can set in firefox to prevent plugins from opening windows. If you set "privacy.popups.disable_from_plugins" to 2 you'll block all popups from plugins, set it to 1 and you'll allow plugins to open windows, but they'll be treated as popups (and limited in the allowed number etc), and set it to 0 and they're unconditionally allowed. Setting this pref may break sites though, as there's no way for a legitimate popup window to come through from a plugin if this is set, etc...

(In reply to comment #32) > Oh, there's now a pref one can set in firefox to prevent plugins from opening > windows. Not Mozilla Firefox only...this was bug 258487, right?

Correct, this didn't make it into the trunk yet.

(In reply to comment #31) > I'm still getting Flash popups from Bath and Body Works: > http://www.bathandbodyworks.com/index.jsp?navid=0.0.0.4.0 WFM. Tested with Mozilla 1.8a5 2004102405 and FF 0.10.1 on WinNT4 with privacy.popups.disable_from_plugins = 2. Popups from Flash are blocked and notified.

I'm assuming that this can be set in about:config, correct? If I filter for this setting (privacy.popups.disable_from_plugins), I get nothing. If I lessen the filter to "privacy" I get: privacy.popups.firstTime privacy.popups.policy privacy.popups.showBrowserMessage privacy.popups.usecustom Am I missing something here? This is the case for me in the Oct 27th RC1 Firefox builds under Windows XP SP2 and Mac OS X 10.3.5.

(In reply to comment #36) > Am I missing something here? Yeah, you've gotta create a new pref, right-click->New... to create a new boolean pref.

If the values can only be 0, 1, or 2, shouldn't it be an integer?

Sorry, yeah, integer. My bad.

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

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

Yet another site that bypasses pop up blocker (unrequested window) through flash (sets a cookie after first load so it only opens once and then again when the cookie expires): http://circuscircusreno.com

(In reply to comment #42) > Yet another site that bypasses pop up blocker (unrequested window) through flash > (sets a cookie after first load so it only opens once and then again when the > cookie expires): http://circuscircusreno.com With the pref from comment 30 and comment 35 this popup is blocked (Mozilla trunk).

Yes you are correct. On 1.8a5 20041122 this flash popup is being blocked and notified using privacy.popups.disable_from_plugins = 2. Will this be included into the preferences section at some point?

I just did a little more testing and this blocking is a little too efficient. Should it not mirror the block unrequested windows setting and only block popups that come up automatically but allow ones where it requires user interaction like when a user clicks on a link within Flash?

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

This hole is high-profile now that Fastclick is abusing it. How does Internet Explorer block pop-ups from Flash? Does it block all pop-ups from Flash (equivalent to setting privacy.popups.disable_from_plugins to 2 in Firefox) or does it somehow detect which pop-ups are requested?

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

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

(In reply to comment #47) > How does Internet Explorer block pop-ups from Flash? Does it block all > pop-ups from Flash (equivalent to setting privacy.popups.disable_from_plugins > to 2 in Firefox) or does it somehow detect which pop-ups are requested? From http://blogs.msdn.com/jeffdav/archive/2004/03/22/94080.aspx "The compat with Flash is a more difficult problem, since the Flash control will be handling the mouse clicks, not mshtml.dll, so in RC1 those new windows will be blocked, unless the site is in the allow list. However, we have a public way for ActiveX controls and applications hosting the webbrowser control to explicitly tell trident to enter and leave the user intiaited action context." That's Windows XP Service Pack 2 Release Candidate 1, not the final version. Further research gave conflicting information about whether this behaviour is the same in the final version though I saw lots of reports that it lets user-initiated popups from Flash through. It seemed to block the Flash-launched Fastclick popups in my tests.

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

1.0.1 has shipped, clearing nomination

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

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

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

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

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

Not 1.0.3

Also occurs with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

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

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

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

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

not 1.0.5 either

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

Adding http://www.ucomics.com/boondocks/ http://legostargalactica.keenspace.com/ to the list of sites getting around the popup blocker. Ucomics and Keenspace are proabably doing this generally, and not just with these two comics, but I haven't specifically tested for that.

(In reply to comment #66) > Adding > > http://www.ucomics.com/boondocks/ > http://legostargalactica.keenspace.com/ > > to the list of sites getting around the popup blocker. Ucomics and Keenspace are > proabably doing this generally, and not just with these two comics, but I > haven't specifically tested for that. Neither of these had popups with this version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050614 Firefox/1.0+ ID:2005061410

(In reply to comment #67) > (In reply to comment #66) > > Adding > > > > http://www.ucomics.com/boondocks/ > > http://legostargalactica.keenspace.com/ > > > > to the list of sites getting around the popup blocker. Ucomics and Keenspace are > > proabably doing this generally, and not just with these two comics, but I > > haven't specifically tested for that. > > > > Neither of these had popups with this version: Mozilla/5.0 (Windows; U; Windows > NT 5.1; en-US; rv:1.8b2) Gecko/20050614 Firefox/1.0+ ID:2005061410 I'd got them with Mozilla 20050524XX. Retesting with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050614 still give me popups from Boondocks. I didn't get one from legostargalactica, but I suspect that the popups are set somehow, in these two cases at least, to only show up once a day. I'll check again tomorrow.

(In reply to comment #68) > I'd got them with Mozilla 20050524XX. Retesting with > > Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050614 > > still give me popups from Boondocks. I didn't get one from legostargalactica, > but I suspect that the popups are set somehow, in these two cases at least, to > only show up once a day. I'll check again tomorrow. And retesting today with the same config got the same result. So, http://legostargalactica.keenspace.com is sending popunders. http://www.ucomics.com/boondocks is not sending popunders. After some cookie deletions, boondocks DID send a popunder. So, not only are they sending the windows, but they're trying to cover for it. If it matters, I'd be happy to do some more cookie juggling and report on what I get.

This is the long-term fix for this problem, a new API that lets plugins enable/disable popups. The new API is NPN_PushPopupsEnabledState(NPP, NPBool) and NPN_PopPopupsEnabledState(NPP), those new functions can be used by a plugin to enable/disable popups while executing code where popups should be enabled. We'll need new plugins that support this before this new API does us any good. So as an interim fix for this problem this patch disables popups from plugins by default and adds code to enable popups when handling key and mouse input events in plugins (Win32 and Mac only since we can't do this on Linux AFAIK).

Comment on attachment 186611 [details] [diff] [review] Add ability for plugins to control popups r+sr+a=me, looks good. /be

+ // Make sure the plugin didn't leave popups enabled. + if (mPopupStates.Count() > 0) { + nsCOMPtr<nsIDOMWindow> window = GetDOMWindow(); + nsCOMPtr<nsPIDOMWindow> piwindow = do_QueryInterface(window); + + if (piwindow) { + piwindow->PopPopupControlState(openAbused); doesn't this need more than one pop in some cases?

(In reply to comment #72) > + // Make sure the plugin didn't leave popups enabled. > + if (mPopupStates.Count() > 0) { > + nsCOMPtr<nsIDOMWindow> window = GetDOMWindow(); > + nsCOMPtr<nsPIDOMWindow> piwindow = do_QueryInterface(window); > + > + if (piwindow) { > + piwindow->PopPopupControlState(openAbused); > > doesn't this need more than one pop in some cases? Maybe. The stack management is not internal to the implementation of the popup state code, it's not really implemented as a stack, but the callers of it in mozilla code make it work like a stack. What this is meant to do is to simply reset the internal state to openAbused. The popup state "stack" *can* still end up incorrect if a plugin misbehaves badly... Feel free to file a followup bug to clean up this code to make it more fool proof... This change is checked in, marking FIXED.

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

Hardware to All. On mac too.

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

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

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

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

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

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

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

Is it intentional that npapi.h has NPN_PushPopupEnabledState() NPN_PopPopupEnabledState() rather than: NPN_PushPopupsEnabledState() (note "popups") NPN_PopPopupsEnabledState() at: http://lxr.mozilla.org/mozilla/source/modules/plugin/base/public/npapi.h#714

This really has to be correct for plugin developers.

Comment on attachment 194069 [details] [diff] [review] Fix npapi.h Yeah, duh. This should indeed be changed for 1.8 IMO. Trivial and safe change.

Plusing for 1.8b4. /be

Comment on attachment 194069 [details] [diff] [review] Fix npapi.h API spelling rectitude, gotta have it. /be

npapi.h patch landed on trunk and branch.

Ucomics has figured out a way around the fix... http://www.ucomics.com/forbetterorforworse/2005/10/11/

(In reply to comment #89) > Ucomics has figured out a way around the fix... > > http://www.ucomics.com/forbetterorforworse/2005/10/11/ > This appears to be a fastclick "innovation". It is opening popunder windows on page unload using flash. I also see this on http://wsls.com/ which is also fastclick related. See this in today's ff 1.8 branch build. And yes, I do have privacy.popups.disable_from_plugins set to 2. Johnny, should we open a new bug?

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

I filed bug 313337 for comment 89 and comment 90.

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

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