W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [IndexedDB] A "versionchangeblocked" event

From: Jeremy Orlow <jorlow@chromium.org>
Date: Thu, 23 Sep 2010 10:43:39 +0100
Message-ID: <AANLkTimPDPU_q=nVkUAY8T53xnbmw00xoQgpAVPWYvsr@mail.gmail.com>
To: ben turner <bent.mozilla@gmail.com>
Cc: public-webapps WG <public-webapps@w3.org>
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?

Received on Thursday, 23 September 2010 09:44:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC