Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Algorithms triggered by user activation and window.postMessage / MessageChannel / BroadcastChannel #4741

Closed
fred-wang opened this issue Jun 28, 2019 · 5 comments

Comments

@fred-wang
Copy link
Contributor

Consider this testcase:

<script>
  onmessage = function() {
    window.open(...)
  }
</script>
<iframe src="some-url"></iframe>

where some-url looks like this

<button onclick="parent.postMessage(..., '*')">Open Popup</button>

As I understand, if one clicks the button of the iframe, the event handler of the parent frame will be able to open a popup, because the algorithm is triggered by user activation:

https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation
https://html.spec.whatwg.org/multipage/browsers.html#popup-blocker

That seems to be how it is implemented in browsers. However browsers behave differently when the message is instead passed by MessagePort (or BroadcastChannel): http://output.jsbin.com/cidetu

I wonder if the spec should be more explicit about how to handle these cases. I see there are similar discussions elsewhere in e.g. #4730

Tentative WPT test (manual because limitation with wpt infra): web-platform-tests/wpt#11668
WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=186593#c3
Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=851493
Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1469422

@mustaqahmed
Copy link
Contributor

Thanks for filing this bug, this is just another example of the problem we have with the current spec.

The behavior defined by the current spec is very hard to implement, and browsers don't behave consistently even without MessagePort or BroadcastChannel!

The good news it that in Chrome, we already changed the user activation model to User Activation v2 which supports the use case you mentioned. We proposed to change the HTML spec to UAv2, see the pull request.

@mustaqahmed
Copy link
Contributor

This issue can be marked as fixed now: all these "chaining" mechanisms now work implicitly through User Activation v2 (#1903).

@domenic
Copy link
Member

domenic commented Oct 28, 2020

@mustaqahmed, to confirm, the reason they work is because of the transient activation duration?

@mustaqahmed
Copy link
Contributor

Yes, plus because of implicit propagation in the frame tree. Before UAv2, a token would have to be propagated to the receiver frame (Window) through every possible chaining mechanisms (postMessage, MessageChannel, BroadcastChannel, setTimeout, Promise, ...). Now the visibility in the frame tree is defined in the spec, and the browser is responsible for appropriate propagation.

@domenic
Copy link
Member

domenic commented Oct 28, 2020

Ah, right. Thanks for explaining! Indeed, let's close this \o/

@domenic domenic closed this as completed Oct 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants