You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
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.
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.
Consider this testcase:
where some-url looks like this
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
The text was updated successfully, but these errors were encountered: