[w3c/IndexedDB] Clarify interaction of IndexedDB lifecycles with relation to document and worker lifecycle mechanics (Issue #416)

https://github.com/w3c/IndexedDB/issues/381 mentions https://w3c.github.io/IndexedDB/#database-connection which says:
> If the execution context where the [connection](https://w3c.github.io/IndexedDB/#connection) was created is destroyed (for example due to the user navigating away from that page), the connection is closed.

https://github.com/w3c/IndexedDB/issues/412 ("Specify behavior when document is not fully active") is also relevant.

The motivation for raising this issue was looking into [IndexedDB/ready-state-destroyed-execution-context.html](https://searchfox.org/mozilla-central/rev/202c48686136360a23b73a49b611a19e64f3e1b8/testing/web-platform/tests/IndexedDB/ready-state-destroyed-execution-context.html#21-24) WPT from https://github.com/web-platform-tests/wpt/pull/30260 (sync of https://chromium-review.googlesource.com/c/chromium/src/+/3125334) for our [Firefox bug on fixing our test failure there](https://bugzilla.mozilla.org/show_bug.cgi?id=1878146).
```js
const openRequest = iframe.contentWindow.indexedDB.open(dbname);
assert_equals(openRequest.readyState, 'pending');
iframe.remove();
assert_equals(openRequest.readyState, 'done');
```

I think the motivation for the test was primarily to verify that `readyState` returned a value rather than throwing, rather than trying to dictate that the state would be "done".

Digging into the iframe spec stuff here, it looks like:
- ["The iframe HTML element removing steps, given removedNode, are to destroy a child navigable given removedNode."](https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element:the-iframe-element-7)
- [destroy a child navigable](https://html.spec.whatwg.org/multipage/document-sequences.html#destroy-a-child-navigable) calls [destroy a document and its descendants](https://html.spec.whatwg.org/multipage/document-lifecycle.html#destroy-a-document-and-its-descendants) which then says
  > [Queue a global task](https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-global-task) on the [navigation and traversal task source](https://html.spec.whatwg.org/multipage/webappapis.html#navigation-and-traversal-task-source) given document's [relevant global object](https://html.spec.whatwg.org/multipage/webappapis.html#concept-relevant-global) to perform the following steps:
  > - [Destroy](https://html.spec.whatwg.org/multipage/document-lifecycle.html#destroy-a-document) document.
- [destroy a document](https://html.spec.whatwg.org/multipage/document-lifecycle.html#destroy-a-document) has some hard-coded message port stuff, but the key thing is it calls [unloading document cleanup steps](https://html.spec.whatwg.org/multipage/document-lifecycle.html#unloading-document-cleanup-steps) which has some explicit steps and then names and shames some specs that haven't done that.  Of those specs, the most relevant to IDB are:
  - [web locks unloading document cleanup steps](https://w3c.github.io/web-locks/#termination-of-locks)
  - [file api unloading document cleanup steps](https://w3c.github.io/FileAPI/#lifeTime)

Notably, as I read it, destroy a document explicitly is happening asynchronously, so it seems like any calls made after an iframe removal can only be reacting to not being fully active since IDB-specific hooks would not have been able to run yet.

### Potential clarification

I think clarifying the existing spec text would basically look like add a hook to [unloading document cleanup steps](https://html.spec.whatwg.org/multipage/document-lifecycle.html#unloading-document-cleanup-steps) that calls [close a database connection](https://w3c.github.io/IndexedDB/#close-a-database-connection) but where we need something other than the "forced flag" because the forced flag would ([correctly for its use case](https://w3c.github.io/IndexedDB/#ref-for-close-a-database-connection%E2%91%A0)) abort transactions where commit() has been called, but where we still want to abort the transactions.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/416
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/416@github.com>