[w3c/IndexedDB] How should IDB connections and outstanding IDB transactions behave when a page enters back/forward cache? (Issue #381)

When a page navigates away with an open IDB connection, the connection gets closed as the execution context gets destroyed ([spec](https://www.w3.org/TR/IndexedDB/#database-connection)). However, as back/forward cache navigation preserves the execution context, if we allow pages with open IDB connections, they would remain open as is.

When should the page be marked unsalvageable after entering back/forward cache? For example, another page could issue a version update request, or delete request to the page in back/forward cache. In these cases, other pages can see the back/forward cache page, and thus probably should be marked as unsalvageable (evict the page from back/forward cache). 

If this is the case, [the spec here about IDB version change](https://w3c.github.io/IndexedDB/#open-a-database) should change to say something like “If the page is not active but salvageable, do not send the versionchange event, but the page should be marked as unsalvageable”. 

Similarly, when a page navigates away with outstanding IDB transactions, they normally get aborted. For back/forward cache navigation, is it okay to mark the page as salvageable even with the transactions, and let them complete? 

There are guidelines [here](https://w3ctag.github.io/design-principles/#support-non-fully-active) about how non-fully-active documents should generally behave with APIs, so please evaluate if these proposals fit the common patterns.

@fergald @dmurph @rakina

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/381

You are receiving this because you are subscribed to this thread.

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