Should we specify behavior for using objects from detached contexts?

[mfalken]

Chromium has some tests which I'm looking to upstream to WPT that do something like:

var registration = iframe.contentWindow.getRegistration(...);
iframe.remove();
registration.unregister();  // expect InvalidStateError

Or

var worker = frame.contentWindow.navigator.serviceWorker.controller;
frame.remove();
worker.postMessage('');  // expect InvalidStateError

I was just going to upstream them, but discovered we originally didn't plan to make these WPT tests because the spec doesn't specify behavior for these detached window cases.

Should the spec specify behavior for these? Any concerns if we just upstream them as WPT tests now even if there might not be spec text?

[wanderview]

I doubt we are aligned here yet, but it would be good to do so. I would say land the test with a comment that clarifies this is currently underspecified and there is room for improvement. We can then iterate on the test.

[mfalken]

Upstreamed as detached-context.https.html

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

[wanderview]

Thanks for landing the test. It seems it touches on a somewhat contentious bit of the promise spec, though. Apparently chrome calls resolve()/reject() callbacks when the promise's owning global is detached, but firefox does not. This make the check for promise rejection timeout in firefox:

https://github.com/w3c/web-platform-tests/blob/master/service-workers/service-worker/detached-context.https.html#L44

@mattto Would you be ok if we loosened this part of the check somehow?

[wanderview]

See:

whatwg/html#2087
whatwg/html#2621

[mfalken]

Sorry I missed this, yes I'm ok loosening the test especially given the comment at the top about unspecified behavior. I think the main reason for the test was to test a crash fix. 2018/02/07 午前3:17 "Ben Kelly" <notifications@github.com>:

…

Thanks for landing the test. It seems it touches on a somewhat contentious bit of the promise spec, though. Apparently chrome calls resolve()/reject() callbacks when the promise's owning global is detached, but firefox does not. This make the check for promise rejection timeout in firefox: https://github.com/w3c/web-platform-tests/blob/master/ service-workers/service-worker/detached-context.https.html#L44 @mattto <https://github.com/mattto> Would you be ok if we loosened this part of the check somehow? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1221 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABsxUj4wJBShNQ0mqXSIqCV8c3xfkhQrks5tSJdEgaJpZM4QXD49> .

[wanderview]

I was thinking we could make the test verify that update() and unregister() don't resolve, but not require them to reject. We could use the "register and activate another dummy scope" to determine how long to wait before declaring that they successfully did not resolve.

[wanderview]

I'm going to fix this in gecko and then uplift since ./wpt serve is not working for me today.

https://bugzilla.mozilla.org/show_bug.cgi?id=1436763

[wanderview]

The update to detached-context.https.html to avoid the explicit check for promise rejection has landed upstream in:

web-platform-tests/wpt#9485