What should happen when accessing lock manager on a non-fully-active document?

[saschanaz]

const iframe = document.createElement("iframe");
document.body.append(iframe);
const n = iframe.contentWindow.navigator;
iframe.remove();
n.locks // what do we want here?

[saschanaz]

The Chrome implementation interestingly silently returns nothing from the methods.

n.locks.request("foo", () => {}); // returns `undefined` instead of a Promise, which violates Web IDL?
n.locks.query(); // same

Should it instead throw?

[inexorabletash]

I suspect both specs and implementations are wildly underspecified/tested here across the platform.

IMHO, I'm happy for the spec to do whatever is most common here, and we can update the Chrome impl. Also, ideally, we'd have somewhere (Infra? WebIDL? dunno) that gives guidance on how APIs should behave in these cases. Maybe even idlharness should be testing these?

Anyway, for web-locks, spec PRs & WPT PRs are very welcome.

[saschanaz]

@marcoscaceres has recently been quite active on this topic. Hi Marcos, what's your expected behavior here? 👀

[marcoscaceres]

Coincidently, the following guidance just got merged into the TAG design guidelines:
https://w3ctag.github.io/design-principles/#support-non-fully-active

(it's what I've been following, with some guidance from @rakina)

I've not looked at this API in any depth - but I'd suggest starting there. It may be you need to simply return a promise rejected with an InvalidStateError.

[inexorabletash]

To the specific question, I think we'd want:

• navigator.locks should still return a LockManager
• The request() and query() methods should throw (reject).

Thoughts?

Also... while full active is defined for documents, is there an easy incantation for Workers?

[inexorabletash]

FYI, c/o @domenic whatwg/html#6379

[asutherland]

Also... while full active is defined for documents, is there an easy incantation for Workers?

I think for workers there are potentially 2 lifecycle-y things?

• The main lifecycle thing for workers is close a worker which sets the workerGlobal's closing flag. Maybe it makes sense that web locks stop working after calling self.close() since the worker's event loop task queues have gone away and your request() can never succeed. So the verbiage might be closing flag is false.
• For ServiceWorkers there's the situation I mentioned in Spec behavior for terminated agents #24 (comment) where there are no pending events. This would involve new incantations in general.

[inexorabletash]

I guess I was wondering what happens in a worker when the owning document goes into BFCache or is in a detached iframe. Does the worker get closed?

[asutherland]

The Worker's lifetime covers the general states and the processing model covers when to suspend which is on transition from "active needed worker" to "permissible worker". The processing model also covers "closing orphan workers". And then there's just explicit termination and explicit self.close().

Speaking from the hip, detached iframe will terminate the worker, bfcache could potentially suspend (noting that interesting documents may tend to be forbidden from going into bfcache because of what's going on in them), but I am absolutely not up-to-date on changes made to specs resulting from standardization of bfcache, just generally aware of Firefox's implementation ramifications related to bfcache. I will edit this paragraph as I inevitably am proven to be wrong in ways big and small as my saying this compels people to reply with (more) correct answers.