Re: [IndexedDB] A "versionchangeblocked" event

Are we really sure this is needed?

I was just writing up a bug for this and started to wonder if we needed any
event when there no longer is a block.  I then realized that once you're
unblocked the onsuccess should fire immediately, so there's no need.  But
wait...isn't this true of normal blocking as well?  Basically either the
onsuccess will fire immediately or onblocked will.  So couldn't an app just
assume it's blocked until it receives a onsuccess message?  The worst case
is that the web app blinks up some message to the user to close other
windows, but it seems like that could happen even with an onblocked event
being added.  Am I missing something here?

J

On Thu, Sep 23, 2010 at 9:57 PM, ben turner <bent.mozilla@gmail.com> wrote:

> I'm voting for 1! I'd hate to give all the other requests a property
> that only setVersion requests will use.
>
> -Ben
>
> On Thu, Sep 23, 2010 at 9:48 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> > On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow <jorlow@chromium.org>
> wrote:
> >> 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?
> >
> > I think that 1 and 2 are the best solutions and I too thought that
> > that was what we had decided on. I don't really see the advantage with
> > 3 since it means that you have to register event handlers on two
> > separate objects, and potentially worry about colliding with other
> > pieces of code doing version upgrades (though the latter problem seems
> > somewhat far fetched).
> >
> > IMHO 2 seems simpler but I don't really care between 1 and 2. I'll
> > note that there is lots of precedence in the HTML5 spec of adding
> > attribute handlers on objects even though they don't necessarily fire
> > on the given object. This was done to keep down the number of
> > interfaces and thus keep things simpler.
> >
> > But if people prefer 1 I'm game for that too.
> >
> > / Jonas
> >
>