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

Re: [IndexedDB] A "versionchangeblocked" event

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 24 Sep 2010 10:44:19 -0700
Message-ID: <AANLkTimWbZ4SEew8eXeDJZBg5oBLY7xKJn54qP_fWez5@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: ben turner <bent.mozilla@gmail.com>, public-webapps WG <public-webapps@w3.org>
On Fri, Sep 24, 2010 at 3:17 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> 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?

I guess it isn't strictly needed, pages can always install a timeout
and cancel that timeout when the success event fires. But I think it
might be worth having still since it's generally hard to get people do
to proper error handling, and so it's extra important to make it easy
for people to do so.

/ Jonas
Received on Friday, 24 September 2010 17:45:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT