Closed Bug 176079 (BlockFlashPopup) Opened 22 years ago Closed 19 years ago

popup blocking does not stop Flash from opening windows

Categories

(Core Graveyard :: Plug-ins, defect, P5)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta4

People

(Reporter: freeatwill, Assigned: jst)

References

(
URL
)

Details

(Keywords: fixed1.8, shockwave)

Attachments

(2 files)

Add ability for plugins to control popups
33.11 KB, patch
brendan
: review+
brendan
: superreview+
brendan
: approval1.8b3+
Details | Diff | Splinter Review
Fix npapi.h
820 bytes, patch
jst
: review+
jst
: superreview+
brendan
: approval1.8b4+
Details | Diff | Splinter Review 
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.
Assignee: mstoltz → beppe
Status: UNCONFIRMED → NEW
Component: Security: General → Plug-ins
Ever confirmed: true
OS: Windows ME → All
QA Contact: bsharma → shrir
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
Summary: Popups not rejected → popup blocking does not stop flash from opening windows
wouldn't it also depend on how the plug-in is designed?
reassign
Assignee: beppe → peterl
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'
Keywords: shockwave
Priority: -- → P5
Target Milestone: --- → Future
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. ***
Summary: popup blocking does not stop flash from opening windows → popup blocking does not stop Flash from opening windows
Updated to a URL that exists.  Mouse over the boxes to get a popup.
URL: http://www.shepherds-bush-empire.co.u... → http://www.pirates.bethsoft.com/flash...
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 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
"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?
Assignee: peterl-bugs → jst
Status: REOPENED → NEW
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
Blocks: 251793
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
No longer blocks: 251793
Should now be fixed by bug 258487, see bug 258487 comment 4 for details. Please
test it with new builds.
Depends on: 258487
Depends on: 150340
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).
QA Contact: shrir → plugins
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?
Blocks: 280326
*** 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?
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.1?
Alias: BlockFlashPopup
*** Bug 283251 has been marked as a duplicate of this bug. ***
Blocks: fastclick-popup
*** 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
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.3?
*** 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
Flags: blocking-aviary1.0.4?
Flags: blocking-aviary1.0.3?
Flags: blocking-aviary1.0.3-
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Blocks: 290396
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
Flags: blocking-aviary1.0.5? → blocking-aviary1.0.5-
*** 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.
Flags: blocking1.8b3+
(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).
Attachment #186611 - Flags: superreview?(brendan)
Attachment #186611 - Flags: review?(brendan)
Comment on attachment 186611 [details] [diff] [review]
Add ability for plugins to control popups

r+sr+a=me, looks good.

/be
Attachment #186611 - Flags: superreview?(brendan)
Attachment #186611 - Flags: superreview+
Attachment #186611 - Flags: review?(brendan)
Attachment #186611 - Flags: review+
Attachment #186611 - Flags: approval1.8b3+
+  // 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.
Status: NEW → RESOLVED
Closed: 21 years ago → 19 years ago
Resolution: --- → FIXED
*** Bug 298616 has been marked as a duplicate of this bug. ***
Hardware to All. On mac too.
Hardware: PC → All
*** 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
Attached patch Fix npapi.h — — Splinter Review 
This really has to be correct for plugin developers.
Attachment #194069 - Flags: superreview?(jst)
Attachment #194069 - Flags: review?(jst)
Attachment #194069 - Flags: approval1.8b4?
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.
Attachment #194069 - Flags: superreview?(jst)
Attachment #194069 - Flags: superreview+
Attachment #194069 - Flags: review?(jst)
Attachment #194069 - Flags: review+
Plusing for 1.8b4.

/be
Flags: blocking1.8b4+
Comment on attachment 194069 [details] [diff] [review]
Fix npapi.h

API spelling rectitude, gotta have it.

/be
Attachment #194069 - Flags: approval1.8b4? → approval1.8b4+
npapi.h patch landed on trunk and branch.
Target Milestone: Future → mozilla1.8beta4
Keywords: fixed1.8
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. ***
Depends on: 315468
Depends on: 776355
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: