Open Bug 1469422 Opened 6 years ago Updated 2 years ago

User gesture is not propagated via window or channel messaging

Categories

(Core :: DOM: Core & HTML, defect, P3)

61 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: dvoytenko, Unassigned)

References

(Blocks 1 open bug, )

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36

Steps to reproduce:

1. Open http://output.jsbin.com/cidetu
2. Click on various buttons inside the iframe: "Window message", "Channel message", etc.

The iframe would send a message to the top window, which would attempt to open a popup.



Actual results:

Popup is blocked.


Expected results:

Popup should be allowed since it happening in the context of a user gesture. Frequently the popup opening is delegated to the top window to ensure the correct referrer and messaging target - this is an important security feature for SSO and Payments services.

Other browsers - Safari and Chrome - allow user gesture propagation (I believe Edge as well, but cannot currently confirm).
I tested this on 

Build ID 	20180621100048
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:62.0) Gecko/20100101 Firefox/62.0


Build ID 	20180605171542
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Firefox/60.0

When I click buttons inside the iframe, notification bar pops up 'Firefox prevented this site from opening pop-up windows' with 'Preferences' button in right
If I go to preferences and select 'Allow pop-ups' for outut.jsbin.com, all pop-ups windows get opened for various buttons of the iframe.

I compared this behavior in Chrome and safari. on Chrome initially/default pop up got blocked for 'Channel message' button. When I selected the same setting/'always allow pop-ups from outut.jsbin.com' all pop-ups were getting displayed. 
On Safari no pop-ups were getting blocked by default.

IMO, this is working as expected. However I placing this under Toolkit:Notification and Alerts, so someone can look into it/expected behavior here. Feel free to change it to more appropriate component.
Component: Untriaged → Notifications and Alerts
Product: Firefox → Toolkit
(In reply to Kanchan Kumari QA from comment #1)
> IMO, this is working as expected. However I placing this under
> Toolkit:Notification and Alerts, so someone can look into it/expected
> behavior here. Feel free to change it to more appropriate component.

I'd definitely disagree with "working as expected". Both Chrome and Safari (and I believe Edge, and even IE) open popups w/o blockers for window messaging ("Window message" button). So I think it'd be great if Firefox followed that pattern rather than being a single major browser that does not.

Channel messaging might be a little more controversial. However, Chrome has already addressed this as well (not sure which version, though) and I see patches for Safari/WebKit as well. It looks to me that differences between window and channel messaging could be just an oversight. I'd recommend addressing both of these right away.
Component: Notifications and Alerts → DOM
Product: Toolkit → Core
I added some links to WPT and other browsers vendor's tracker. However, it seems the case of Firefox is special, as it always block popups, even when the algorithm is triggered by user activation. Probably this does not involved the webmessaging API at all? The relevant section from the spec is:

"If the algorithm is not triggered by user activation and the user agent has been configured to not show popups (i.e. the user agent has a "popup blocker" enabled), The user agent may inform the user that a popup has been blocked."

(see https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name)
(In reply to Frédéric Wang (:fredw) from comment #3)
> seems the case of Firefox is special, as it always block popups, even when

Hmm. You mean blocks popups in WPT? Or in general? Top-level button works ok, but not the one from iframe...
Priority: -- → P3
Component: DOM → DOM: Core & HTML
Blocks: 1577516
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.