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: Mon, 27 Sep 2010 16:18:32 +0100
Message-ID: <AANLkTin4q=s_w9eqdnR_5rth-LEHRhtACr6RqfW5Ri=m@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: ben turner <bent.mozilla@gmail.com>, public-webapps WG <public-webapps@w3.org>
Btw, I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=10765 but emails
from the bug tracker are currently broken.

On Mon, Sep 27, 2010 at 11:29 AM, Jeremy Orlow <jorlow@chromium.org> wrote:

> On Fri, Sep 24, 2010 at 1:44 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> 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.
> Hmmm.  Yeah, I guess I can buy that.
> J
Received on Monday, 27 September 2010 15:19:22 UTC

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