1469045 - postMessage doesn't keep true "isTrusted" value

Status: RESOLVED DUPLICATE of bug 1502801

(Core :: DOM: postMessage, defect, P3)

Description

[gasper]

Attachment: postMessage-window-open.html

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

Steps to reproduce:

1) create a sandboxed iframe with a button inside
2) on button click, send a message to the parent window with postMessage()
3) on "message" event call window.open

See attached file for an example. Also available at https://codepen.io/gasper_k/pen/xzXWeN.


Actual results:

Firefox popup blocker blocks opening of the window.


Expected results:

Firefox should open the window. The message was initiated with a user interaction.

Comment 1

[gasper]

Works in Chrome and Safari, they report isTrusted=true.

Comment 2

[Stefan [:StefanG_QA]]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0 (20180619220118)

I've tested this report on Windows 10 & OS X 10.14 using latest Nightly, Beta and Firefox release build. When navigating to https://codepen.io/gasper_k/pen/xzXWeN and click on the window.open button, the browser prevented the site from opening a popup window. 

Chrome and Safari do not block the popup from opening.
In Edge and IE the window.open button is not displayed.

Based on other similar reports I think the proper component would be Core:DOM:Core&HTML. Please change if this is not the correct component.

Comment 3

[gasper]

http://1.kozak.si/outer.html also works on IE. Tested on IE10 (Win8) and IE11 (Win7). Both block the popup.

Comment 4

[Andrew McCreight [:mccr8]]

This sounds like the same issue as the WPT test wpt/webmessaging/MessageEvent-trusted.html. Firefox is the only browser that fails the test.

Comment 5

[Andrew McCreight [:mccr8]]

The WPT test is basically:
  window.onmessage = t.step_func_done(e => {
    assert_equals(e.isTrusted, true);
  });
  window.postMessage("ping", "*");


Olli, any thoughts?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Now I'm lost. What has the initial comment to do with comment 4 and 5.
popup blocking something totally different to event dispatch.

To fix _this_ bug we either need to propagate user activation flag via postMessage or implement something close to what Google has proposed for a new model for user activation.


MessageEvent-trusted.html shows an issue in 
https://searchfox.org/mozilla-central/rev/9cb3e241502a2d47e2d5057ca771324a446b6695/dom/base/PostMessageEvent.cpp#201
Apparently other browsers consider postMessage as trusted operation.
I guess we should just always pass true there.

Comment 7

[Andrew McCreight [:mccr8]]

Sorry, it sounded related. I can split the WPT failure into a separate bug.

Comment 8

[Jens Stutte [:jstutte]]

(In reply to Olli Pettay [:smaug] from comment #6)

MessageEvent-trusted.html shows an issue in
https://searchfox.org/mozilla-central/rev/
9cb3e241502a2d47e2d5057ca771324a446b6695/dom/base/PostMessageEvent.cpp#201
Apparently other browsers consider postMessage as trusted operation.
I guess we should just always pass true there.

Anne, can you confirm?

Comment 9

[Anne (:annevk)]

The model the specification has for isTrusted is unrelated to user activation. isTrusted is set to true when the user agent dispatches the event. If PostMessageEvent::Dispatch doesn't have (direct) public callers (e.g., window.dispatchEvent(...)) always passing true seems like the right thing.

Comment 10

[Jens Stutte [:jstutte]]

And we already did this in bug 1502801. Sorry for the noise and thanks!