- From: Joshua Bell <notifications@github.com>
- Date: Mon, 21 Mar 2016 09:20:21 -0700
- To: w3c/IndexedDB <IndexedDB@noreply.github.com>
- Message-ID: <w3c/IndexedDB/issues/72/199363274@github.com>
> Did you mean that the behavior displayed in the test code I provided is by design? i.e. the blocked event does not signify the failure of the open operation, but I should ignore it and wait for the other events to proceed? Correct - failure would be signaled by `"error"`. `"blocked"` signals that the open request is unable to proceed at this time. But you don't necessarily need to ignore it... > If that is the case, then how is it possible to differentiate between a "temporary" block - for which I'm supposed to wait for further events, and a "fatal" one meaning a connection is open somewhere (say in another tab, frame or worker) and essentially nothing can be done? That's up to the logic of your application. One approach on receiving `"blocked"` might be — after some short delay — to pop up UI saying "the database is in use by another tab. please wait" if you know that your application will eventually close in response to a `"versionchange"` event, or UI instructing users to close other tabs if not. And obviously remove the UI when the open proceeds. --- 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/72#issuecomment-199363274
Received on Monday, 21 March 2016 16:21:17 UTC