This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
NOTE: the following is a proposal for a future version of IndexedDB Just as an event is fired at a transaction when the transaction implicitly aborts (but not when abort() is called), there are cases where a database connection may close even without close() being called, and script should be notified with an event. Scenarios: * the user invokes the browser's "clear my stored data" option which deletes the backing store * backing store is on a removable storage medium; the browser detects when the medium is removed and further read/write attempts to the database will fail (while file handles will be lost, arguably the implementation could do some magic in this scenario to reestablish the connection behind the scenes, simply failing any attempted transactions with UnknownError in the mean time) Proposal: If the connection to the database is closed other than by a call to close(): 1. set the /closePending/ flag of /transaction/ 2. for each transaction created using /connection/ that is not complete, run the steps for aborting the transaction with /transaction/ and "AbortError" 3. fire a "connectionclosed" event at /connection/; the event does not bubble and is not cancelable
FWIW, various other things in the platform already fire "close" events; given that this event is fired at a connection object, that's probably a bettername.
step 1 should be: set the /closePending/ flag of /connection/ Also, it should be made clear that this does not apply to connections closed via GC, context destruction, etc. Thanks, Kyle!
One bit of developer feedback already - this should include a message indicating the reason for the closure. (e.g. user deleted the backing store, I/O error, etc) There's no generic |message| property on Event, so either we need to define a custom Event type or add one to DOM Event.
Regarding Josh's suggestion for a closure reason, here's my proposal. == Scenarios == Use case #1 - Normal closure caused by page In this case the web page will: 1. Open a connection to database. 2. Register a close event handler. 3. Optionally read/write data from/to the database. 4. Script calls close() on the IDBDatabase connection object. Use case #2 - Normal closure caused by browser In this case the web page will: 1. Open a connection to database. 2. Register a close event handler. 3. Optionally read/write data from/to the database. When the database is open the user will then: 1. Display browser settings. 2. Choose to clear client data (like "Clear cookies and other site data"). In this use case the page did not initiate the closure. Use case #3 - Error in backing store forced closure. In this case the web page will: 1. Open a connection to database. 2. Register a close event handler. 3. Read/write data from/to the database. During the execution of the reads/writes in step #3 the backing store encountered an error which requires the connection to be closed. == Proposal == The proposed solution is to fire a "close" event at the IDBDatabase object, as previously suggested, but the event will implement the new IDBConnectionCloseEvent interface interface IDBConnectionCloseEvent : Event { readonly attribute DOMString reason; readonly attribute DOMString message; }; The values for these attributes are as follows. reason: ------- "closed" "user" "error" message: -------- This would contain any additional information the browser may want to supply. Some examples might be: "Closed by page" "Deleted all user data" "Database corrupt: Checksum mismatch"
Any opinions on cmumford's proposal? Chrome is already firing a close event in the abnormal case per my description (and refined by comments 1-2), but it doesn't introduce a new type to the platform and since it's abnormal-close only it can't be relied upon by pages.
Pinging again - any opinions from other implementers?
I don't have an opinion on the whole "reason"/"message" discussion. Similar attempts in other APIs have so far been failures. Dominic Denicola is a good person to talk to here. But that aside, a "close" event on connections, as well as the transaction abort handling sounds good to me.
I took a stab at specifying this in: https://github.com/w3c/IndexedDB/commit/6bce2d57d5ac9dbfc68c24a69396217cdd5bfa0a TL;DR: If connection closes abnormally, abort any outstanding transactions, then fire "close" at the IDBDatabase. No reason/message. (This matches the behavior shipping in Chrome.)