315468 - Popup blocker blocks user initiated popup from Flash (actionscript onpress)

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[davide.pulver]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

In general a popup blocker should only block unwanted popups. 
User initiated popups should always be allowed.

Reproducible: Always

Steps to Reproduce:
1. open the page
2. Click on the link "3D Gallery" on the bottom left

Actual Results:  
Firefox prevents the site from opening a popup window

Expected Results:  
Open the window because it's user initiated

I also performed the test at http://www.dancesoft.com/browsertest.htm
with the same problem.

Comment 1

[Jesse Ruderman]

This happens for some Flash pages but not for others.  For example, the "3D Gallery" link on http://www.naturevibes.com/index2.html doesn't work, while the "Go" button on http://www.deepfriedlive.com/ does work.  What are the two Flash files doing differently?

Comment 2

[davide.pulver]

In the "3D Gallery" link on http://www.naturevibes.com/index2.html the javascript:window.open function is embedded in the flash movie.
The "Go" button on http://www.deepfriedlive.com/ is calling the function do_it in the html page.

The window.open function is working fine if it's coded in the html. If the function is directly called in the flash movie, the popup blocker doesn't allow it.

Comment 3

[davide.pulver]

I did some tests now and found out the problems:

- First, the window.open function has to be done in html instead in flash movie (as mentionned before)
- Second, in Flash actionscript, the action used to open the link has to be "on (release). While I was using the action "on (press)" the popup blocker always blocked the windows, regardless of where the window.open was done$

Comment 4

[Jesse Ruderman]

Peter Grandmaison, can you help us figure out if this is a bug in Flash or a bug in Firefox?

Comment 5

[Jesse Ruderman]

(or intended behavior -- Firefox has some of that too, see bug 239403 / bug 304827.)

Comment 6

[OstGote!]

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

Comment 7

[OstGote!]

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

Comment 8

[OstGote!]

This is intended, see bug 176079.

This is due to the new privacy.popups.disable_from_plugins pref. Try to change it  to 0 or 1.  Or whitelisting the site in the popup blocker will work too.

Comment 9

[Jesse Ruderman]

I don't think this is intentional.  Macromedia and we are trying to make user-initiated popups from Flash work, and they do work in some Flash pages.

Comment 10

[Peter Grandmaison]

Attachment: Test movie

This movie demonstrates that popups from WM_LBUTTONDOWN AKA on(press) are blocked, but WM_LBUTTONUP AKA on(release) are not blocked.

Comment 11

[Peter Grandmaison]

Attachment: Source to attached SWF

Comment 12

[Peter Grandmaison]

ActionScript event handler on(release) is invoked in response to WM_LBUTTONUP -- this is working correctly.

ActionScript event handle on(press) is invoked in response to WM_LBUTTONDOWN -- this is not working correctly.

I expect FireFox is calling NPN_PushPopupsEnabledState() before dispatching the WM_LBUTTONUP, but not WM_LBUTTONDOWN. Our expectation is that FireFox wraps all user event dispatch with a push/pop pair.

So I'd say this is a bug with FireFox.

Comment 13

[Peter Grandmaison]

Attachment: HTML file embedding test SWF

Comment 14

[u236425]

I have seen the same problem, trying to click on a macromedia flash banner ad under linux using firefox 1.5.0.1 -- nothing happens, if the popup blocker is enabled. if I disable the popup blocker, I can get a clickthrough from a flash banner ad to the destination url just fine.

Comment 15

[Jesse Ruderman]

Ere, jst, biesi, do you know who should own this?  This breaks a lot of Flash content.  See comment 10 through comment 13 for some analysis from Peter Grandmaison at Macromedia.

Comment 16

[Ere Maijala (slow)]

I don't think it's anything I'm too familiar with unless the problem lies in Win32 widget code, which seems unlikely.

Comment 17

[Tracy Walker [:tracy]]

I see similar blocking of Macromedia's About link from context click of flash content.  You have to allow popups for the site to get the macromedia about page.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Jst will try to talk with the flash people and see if it's possible to get them to use our popup blocker API to fix this in the plugin

Comment 20

[Johnny Stenback (:jst)]

(In reply to comment #12)
> ActionScript event handler on(release) is invoked in response to WM_LBUTTONUP
> -- this is working correctly.
> 
> ActionScript event handle on(press) is invoked in response to WM_LBUTTONDOWN --
> this is not working correctly.
> 
> I expect FireFox is calling NPN_PushPopupsEnabledState() before dispatching the
> WM_LBUTTONUP, but not WM_LBUTTONDOWN. Our expectation is that FireFox wraps all
> user event dispatch with a push/pop pair.
> 
> So I'd say this is a bug with FireFox.

Peter, you're right, we enable popups only when handling WM_LBUTTONDOWN, but not when handling WM_LBUTTONUP. While we could relatively easily change that, doing that won't fix the whole problem across platforms. What we have right now in Firefox is a windows specific hack to partially work around this problem. This hack is also furhter complicated by the fact that when sending a WM_LBUTTONDOWN message to the flash player, it doesn't actually act on that right away, do we can't disable popups after having passed that message to the flash player. To get around that we also have code that delays the disabling of popups until we get back to the main event loop again.

That's of course why popups from flash don't work at all on Linux, and there it's non-trivial for the browser to intercept the events that are going to the plugin, so we can't easily add a similar hack for Linux (on Mac we could, but we'd rather not).

This was done some time ago when we didn't have an API for plugins to do this themselves. And this was the reason for adding NPN_PushPopupsEnabledState() and NPN_PopPopupsEnabledState(), so that plugins could do this right, across platforms. And especially given delayed actions to certain messages etc, it really is the plugin that should manage this rather than expecting the browser to do it for them.

Given that, I *really* don't want to change anything in the browser relating to this, except maybe take out our hacks once a flash player exists that manages popup enabled state on its own.

Unmarking the blocking flag, setting this to be nominated as a blocker to track what to do here.

Comment 21

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This needs to be fixed on the plugin side. We're in talks with adobe about it.

Comment 22

[Paul Betlem]

The Flash Player team will be investigating shortly and will respond back.

Comment 23

[Ed Costello]

Created bug in Adobe's Flash Player bugbase.  Reference #212291

Comment 24

[zug_treno]

With Flash Player version 9.0.115.0 installed neither the blue button nor the green button of the attached Test movie open a new window, see bug 414460.

Comment 25

[Ciprian Muresan [:cmuresan], Formerly of Ecosystem QA - please needinfo @mcoman for things regarding the team]

Hi,

User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0

The issue is no longer reproducible on the latest Firefox Release (46.0, Build ID 20160421124000) and the latest Nightly (49.0a1, Build ID 20160427030215). I used the testcase from comment 10 and both buttons work correctly. 
Considering this I will mark this issue as RESOLVED-WORKSFORME. If anyone still encounters this issue, feel free to reopen this one or file a new one.

Thanks,
Cipri