Re: [IndexedDB] A "versionchangeblocked" event

On Wed, Sep 22, 2010 at 9:07 PM, ben turner <bent.mozilla@gmail.com> wrote:

> Hi folks,
>
> While implementing the latest setVersion changes Jonas and I decided
> that it would be really useful to be able to signal to the caller that
> other web pages are open and using the database (thus preventing a
> setVersion transaction from running).
>
> Consider a web page open in two windows, one minimized or otherwise
> obscured and the other in the foreground. If the background window is
> running a transaction then the foreground window will not be able to
> immediately begin a setVersion transaction when it makes that request.
> The spec currently informs the background page that it should close
> all its databases, but it would be even more useful to inform the
> foreground page that it is currently blocked. That way the foreground
> page could display some kind of notification ("Hey, you! Go close your
> other tabs if you want us to upgrade the database!") that would aid
> the process. We are also relying on page authors to correctly call
> close() on their databases in response to the "versionchanged" event
> and I don't believe that they will always follow through.
>
> Jonas and I thought of three possibilities:
>
> 1. Make setVersion return a special kind of request that had an
> "onblocked" event handler. The caller could then add a handler just as
> they do for success and error conditions.
> 2. Make all IDBRequests have an "onblocked" handler, but just never
> call it in other situations.
> 3. Fire a "versionchangeblocked" event at the database.
>
> What do you guys think? Any preferences? I don't really like 2, and
> I've preemptively implemented 3, but I'm not in love with 1 or 3
> either.
>

This exact thing came up when we originally talked about setVersion.  I
thought Jonas proposed and we decided on 1 (though I'm not against 3)..?
 Did this just not make it into the spec?

J