Current spec text:

"The connection can be closed through several means. If the connection is GCed or execution context where the connection is created is destroyed (for example due to the user navigating away from that page), the connection is closed. The connection can also be closed explicitly using the steps for closing a database connection."

So, obviously, the spec shouldn't reference GC. It would capture the intent to say something like:

"If the connection object can no longer be used (for example, the user has navigated away from the page, or no references to the connection remain), the connection may be closed."

The more fundamental issue is that script can tell if GC has happened, e.g.

db = indexedDB.open('db', 1);
indexedDB.open('db', 2).onsuccess = function() { alert('GC happened'); };
db = null;

... which would preclude the use of the API in this fashion in e.g. a hypothetical environment with infinite memory.

I think that ship has already sailed with connection-type resources. For example, with Web Sockets - open two sockets to a server, drop the reference to the first, and when the server detects that the first is unusable it can signal the second. Just riffing, though.

We should check the IE behavior here.

I noticed that XHR deals with this explicitly:

https://xhr.spec.whatwg.org/#garbage-collection

"An XMLHttpRequest object must not be garbage collected if..."

Chromium doesn't allow GC unless closePending or it has no event listeners. I believe FF does something similar (or maybe never GCs open databases?)

So we could add wording such as:

"An IDBDatabase object must not be garbage collected if its closePending flag is false and it has one or more event listeners registers whose type is one of abort, error, and versionchange."

I agree that it's unfortunate to expose GC behavior here. But I don't see any alternative solution.

The only option I could think of would be to never close databases unless the .close() function is explicitly called. It's not clear that that's web compatible at this point though.

So let's not hold up the v1 spec for this at the very least.

I don't understand. What about addressing comment 3 at least?

How is that different from the option I mentioned in comment 4?

I added some blather similar to comment #3 into:

https://github.com/w3c/IndexedDB/commit/bdfc9964855d0ad650ade6da3ed0dd9b43b69d6a

... but I welcome more refinement. Leaving this open until we really nail down how to describe this.

Moved to https://github.com/w3c/IndexedDB/issues/29