spec behavior when ServiceWorkerContainer parent client is dead

[wanderview]

This is kind of a corner case, but I don't think the spec really handles it currently:

1. open a random webpage
2. w = window.open("./")
3. sw = w.navigator.serviceWorker
4. close the new tab from step 1
5. sw.register("whatever.js");

In this case we're calling .register() for a window that is already closed. I'm intending to reject with InvalidStateErr, but I guess it would be nice to spec it.

[wanderview]

Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1221351

[wanderview]

I guess to be more accurate, gecko is going to return a rejected promise, but we don't fire promise callbacks for closed windows. So the .catch() callback won't fire.

[wanderview]

It appears chrome canary returns undefined instead of a promise object in this case.

[jungkees]

I think the question here is more in general what the behavior of accessing APIs hang off a destroyed object should be. Do we have any existing language that specifies this?

/cc @annevk @bzbarsky @domenic

[bzbarsky]

The object is not destroyed, kinda sorta. Existing spec language assumes that all things leak forever and the browser never cleans anything up. Clearly that's not reasonable, so in practice browsers by and large implement different things which are not interoperable. Sometimes browsers are not internally consistent (e.g. treating removing an iframe from the DOM tree one way in terms of what happens to the Window currently in it and navigating the iframe in a different way, and closing a toplevel tab in yet a third way).

Oh, and there may be some actual web compat constraints around this stuff for some APIs. I seem to recall that when Gecko tried turning off scripts altogether in a Window whose iframe has been removed from the DOM we ran into web compat issues.

None of that helps you with your current situation, of course...

[mkruisselbrink]

https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/platform-architecture-dev/CaIci4Ezebs/9cpUzZ1yAgAJ has some recent blink discussion about this as well.

[jakearchibald]

F2F:

• Seems like browsers keep windows alive when there's a reference held within
• This is a much bigger web compat problem, and needs to be solved at a lower level
• Do we do fetches from a detached iframe? We don't SW control these, and should spec that
• Are detached iframes controlled?
• If you add/remove iframe
• This is another good argument for the clientcontrolled event
• Happy for methods to fail (throw/reject) if the window is detated, properties shouldn't throw, but may return undefined/null

[jakearchibald]

• Add non-normative note about this
• Cover it with WPTs

[aliams]

Seems like browsers keep windows alive when there's a reference held within

In Edge, the reference is emptied (that is, the object has no properties nor functions) when the window is closed. This means that you are not able to access anything which makes it not possible for us to fail by throwing an error or returning a rejected promise.

[jakearchibald]

Notes:

• We might be able to make these APIs work without a browsing context, but we should ask implementors because I don't think devs care much either way
• Feedback from MS is important here

[jungkees]

We move this to V2 to have more discussion and experiments.