Intent to Implement and Ship: Don't allow popups during page unload

[Avi Drissman]

Contact emails

a...@chromium.org

Summary

A web page can use the window.open() API to create popups or tabs. This is a highly abusable feature, so we have a system in place called the "popup blocker" to put strict limits on the use of this API.

Motivation

I would like to remove the ability of a page to use the window.open() API during page unload, whether or not the popup blocker is enabled. This would simplify browser shutdown and improve our ability to make it correct.

This is mostly already prohibited by the popup blocker which is enabled by default; as such it is minimally web-visible.

Implementation

https://chromium-review.googlesource.com/c/chromium/src/+/1065466

Interoperability and Compatibility

Edge: No Signals

Firefox: No Signals

Safari: Shipped

Web developers: No Signals

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

No; can WPTs test opening windows/failure to open windows?

This is tested by Chromium's browser tests.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5989473649164288

Ship bug

https://crbug.com/844455

Requesting approval to ship?

Yes.

[Charles Harrison]

The tricky part of testing this via WPT will be evaluating success/failure after the unload handler is called on the page :)

For determining whether a window was opened, you should be able to just inspect the return value of `window.open`.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACWgwAYbX5Um36P2m3XCD_0bPvpm%2B5nX2%2BDwYPTU1GOo6k4pkA%40mail.gmail.com.

[Avi Drissman]

[oj...@google.com]

LGTM1

Is it hard to add a histogram or UseCounter while you're at it? That way if we get complaints of site breakage, we'll be able to reason about it and avoid rolling back.

[Boris Zbarsky]

On 5/18/18 4:40 PM, Avi Drissman wrote:
> I would like to remove the ability of a page to use thewindow.open()API
> during page unload

Just to check, which page? The one that lives in "window" (relevant
global), the one the "open" method comes from (current global), the one
making the call (incumbent global) or something else?

What is the definition of "during page unload" being used here?

-Boris

[Avi Drissman]

Apologies, this is a double post. Please post on the other thread.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7d5b1e13-8eba-4a14-b261-499bd610384b%40chromium.org.

[Fernando Serboncini]

If this already happens with the popup blocker on, this change would prevent a site from creating a popup EVEN if the user has given explicit permission to allow popups from this site. Is this true? And if so, what's the reasoning behind this?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e6ff1e11-0a64-2d99-713d-f38813cc1bd4%40mit.edu.

[Philip Jägenstedt]

Avi, do you have a pointer to what Safari has shipped?

Since this is web exposed, should we change the spec to match what Safari already does and ship that? I think it's https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name that needs to be tweaked here, by consulting some notion of "during page unload", which gets to Boris's question.

It ought to be possible to test this in WPT by window.open()ing another window which is tries to open a popup while being unloaded. If nothing else, the would-be-opened popup could postMessage something, and if that message isn't received the test passes.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADp2-T9yqoyWigC%2B09u4Yf%3D8tnjj7pPHyei8%2BMa8%3D8La2qNiwA%40mail.gmail.com.

[PhistucK]

But postMessage is asynchronous, if I remember correctly, so the window may close before it has a chance to receive a message? On the other hand, postMessage from the opener to the popup would be received by the popup if it is open and fail the test, if that is possible.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcKy5LUKWneed%2BPUzns_XnBpeLEGCtw8B413ejQ4P1d3Q%40mail.gmail.com.

[Philip Jägenstedt]

I mean that the window which shouldn't be opened posts a message, and if that message is received the test fails. This style of test a last resort, because it means that the pass condition is "nothing happened" after a timeout.

[Avi Drissman]

I don't have a pointer; this is based on experimentation with Safari on my machine.

[mk...@chromium.org]

My understanding of Avi's proposal is that a page shouldn't be able to call `window.open()` from a `beforeunload` event. Skimming the spec, it seems reasonable to extend that "shouldn't" somewhat widely, perhaps altering the window open steps to exit early if the termination nesting level counter is anything other than 0. That seems marginally simpler than Philip's suggestion that we wait until we're choosing a browsing context (as I don't believe there's any vector other than `window.open()` for opening a new browsing context during `beforeunload`?).

That said, I do agree with Philip that it would be nice to specify the behavior, and add some tests to confirm it. It is certainly web visible in edge cases like opening and closing a same-origin window that opens a same-origin window during its `beforeunload`, then BroadcastChanneling and waiting for a lack of response. Not a great test, but a test.

If you put something like that together, and file a bug against HTML accordingly, LGTM2.

Thanks!

-mike

[Philip Jägenstedt]

Something like that SGTM too. Avi, would it be OK to put this intent on hold until the spec change is done and ready to be merged? Open spec issues, even with agreement, can get left sitting around forever, so I think it makes sense to default to making the spec changes up front.

[Avi Drissman]

Sure.

[Rick Byers]

We discussed this in the API owners meeting today (Ojan, Yoav, Alex, Daniel, Rick).  We agree it's reasonable to require at least a concrete proposed spec/test change along the lines that Mike and Philip are asking for before approving this intent.  Like other interventions, we may not get agreement that the proposal should land prior to shipping it and collecting data on how it works in practice.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACWgwAZtd2e6hXdhkT7%2B%2BP0SKLDBJ9BUBN5yCcV_NqOzc_4maA%40mail.gmail.com.

[Avi Drissman]

Coming back to this.

This landed as a spec change, so may I have approval to land our implementation of it? Pretty please? :)

Thank you,

Avi

[Philip Jägenstedt]

That makes it an an easy case, LGTM1 :)

Looking for the tests led me to https://chromium-review.googlesource.com/c/chromium/src/+/1180296/, so once this is landed the tests will be upstreamed to wpt too. Yay.

[Avi Drissman]

Yes, this has WPT tests by request from this thread.

Your support is appreciated.

Avi

[Yoav Weiss]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACWgwAaqj1nHp2o5onsLLBLuRepAS8ShLDbNzmJxw-Kko%3DwTxA%40mail.gmail.com.

[TAMURA, Kent]

LGTM3.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjFf1kORgBpvVVmpOUhX%2BUvmKpfqaSput-PZXWzuZ3XHA%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Avi Drissman]

To follow up: this landed in 72, but it apparently caused breakage in some enterprise apps.

Therefore, this was reverted in 72 and 73, but is landing again in 74. There will be a policy flag in 74 to allow popups during page unload. That policy flag will be removed in 82, which will allow enterprises time to stop this practice.

I'm updating https://www.chromestatus.com/feature/5989473649164288 .

Avi

[harak...@gmail.com]

2018년 5월 19일 토요일 오전 5시 41분 0초 UTC+9, Avi Drissman 님의 말:

[harak...@gmail.com]

2018년 5월 19일 토요일 오전 5시 41분 0초 UTC+9, Avi Drissman 님의 말:

Contact emails