[w3c/IndexedDB] Provide finer control over open request edge cases (#223)

A couple of scenarios:

### Really blocked upgrades

* Tab 1 opens a connection at v1
* Tab 2 tries to open a connection at v2 - gets `blocked` (Tab 1 gets `versionchange` but can ignore it)
* Tab 3 tries to open a connection at v2 as well; is in limbo state with no `blocked` event. 

This limbo state falls out of the current spec. It's definitely unexpected, and not necessarily intentional, but that's how it works. I think one of the browsers (Firefox? Edge?) may have fired `blocked` here at one point.

Tab 3 can't give useful feedback to the user about what to do; it can only detect this with a timeout.

### Timed out upgrades

So let's say either Tab 2 or Tab 3 wants to defend against Tab 1 being a meanie and not closing the connection by using a timeout. Implementing this is subtle - the app needs to decide at some point that even if a subsequent `upgradeneeded` or `success` comes in then (1) the upgrade should not happen and (2) the connection should be closed, e.g.:

```js
const open = indexedDB.open(name, version);
let abort_open = false;
setTimeout(() => { abort_open = true; }, 1000); // give up after 1s
open.onblocked = e => {
  if (abort_open) return;
  // normal blocked handler here
};
open.onupgradeneeded = e => {
 if (abort_open) { open.transaction.abort(); e.target.result.close(); return; }
 // normal upgradeneeded handler here
};
open.onsuccess = e => {
  if (abort_open) { e.target.result.close(); return; }
  // normal success handler here
};
```

Otherwise you run into problems like https://stackoverflow.com/questions/40032008/how-should-an-app-react-when-indexeddb-is-blocked

Should timeouts be built in? Or tie into `AbortController` or other ways to abort the open request?


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