Sort out interaction of promises with document unloading and browsing context teardown

[bzbarsky]

Consider this testcase: Page A opens a same-origin page B in a new window/tab, page B runs the following code:

(function f() { ++opener.counter; return Promise.resolve().then(f) })()

then the user gets sick of the proceedings closes the window/tab B is in.

What should happen?

Per current spec, the answer is "User can never interact with A again, because that promise loop never terminates". This is in fact what Chrome implements, until it crashes on OOM. Same for Safari. This is obviously somewhat user-hostile; users expect that when they close a page it gets closed.

Firefox seems to show a "would you like to stop this script?" dialog after some time, independently of whether the window/tab is closed or not.

What should the spec require here?

Also, what should happen to attempts to do such promise loops on already-closed or navigated-away-from pages? What should happen on navigation attempts in the middle of a loop like the one above? Can those even happen?

Some relevant reading:

https://bugzilla.mozilla.org/show_bug.cgi?id=1058695
https://bugzilla.mozilla.org/show_bug.cgi?id=1165237
https://bugzilla.mozilla.org/show_bug.cgi?id=1124322

[bzbarsky]

Testcase:

<script>
  var counter = 0;
  var blob = new Blob(["<script>(function f() { ++opener.counter; return Promise.resolve().then(f) })()</sc" + "ript>"], { type: "text/html" });
  var url = URL.createObjectURL(blob);
</script>
<input type="button" onclick="window.open(url)" value="click me">

[annevk]

This seems related to #1989.

I also found that you raised this in https://esdiscuss.org/topic/event-loops-in-navigated-away-from-windows which has a solution of sorts at the end (associate JavaScript jobs with a realm), but I'm not sure if @domenic has taken that into account with his revamp of how JavaScript and HTML are "layered".

I also found domenic/promises-unwrapping#108 which is probably the original sin, if anything. (Another case of TC39 dismissing host integration concerns and those then resurfacing for the next couple of years.)

[annevk]

It seems HTML has had "check if we can run script" since 2016. How does that not address this concern?

[bzbarsky]

Hmm. This is the check at https://html.spec.whatwg.org/#enqueuejob(queuename,-job,-arguments) step 7.1?

That might in fact address the concern. We probably need to get some tests written to test the various edge cases here and then poke browsers to fix things as needed.

[annevk]

Yeah, I'm also somewhat surprised I hadn't seen it before.

[domenic]

This has come up in Chromium a few times now. The spec side issues are w3c/payment-request#872 and WebAudio/web-audio-api#2176.

Basically, for some time in the past I've been encouraging others to write specs like "If this's relevant settings object's responsible Document is not fully active, then return a rejected promise."

However, this advice seems wrong, since per the "can run script" check in the event loop, the promise's rejection handler will almost never be called. It could be called if the document becomes fully active again, which would happen if the document was in the bfcache and then got navigated back to. IMO this is quite bad as it means whether you get the failure signal or not is nondeterministic and non-interoperable, and the failure signal would be significantly delayed from the original operation that caused it.

Instead I've been recently advising people to return a forever-pending promise, so that handlers will never be called (i.e., this gives us determinism). This is a bit weird; there is neither good spec infrastructure nor, apparently, Chromium implementation infrastructure, to do this. But it makes the most sense to me.

Do others have thoughts? I'm getting some pushback in Chromium about this so I think it'd be good to settle the best practices here one way or another.