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

Re: [IndexedDB] blocked event could be an error

From: David Grogan <dgrogan@chromium.org>
Date: Thu, 26 Jul 2012 14:59:58 -0700
Message-ID: <CAOZbSt1iofZu9Waocmjj=yjJ8H-T=r11+1iJnESYQ7LNA2G_UA@mail.gmail.com>
To: Odin Hørthe Omdal <odinho@opera.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
On Mon, Jul 23, 2012 at 11:49 AM, Odin Hørthe Omdal <odinho@opera.com>wrote:

> There are some open issues in the spec that has been there a long time.
> They deal with opening and deleting database.
> http://dvcs.w3.org/hg/**IndexedDB/raw-file/tip/**
> Overview.html#dfn-steps-for-**deleting-a-database<http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-deleting-a-database>
> # 7. Wait until all objects in openDatabases are closed and all of their
> #    transactions are finished.
> #
> #    ISSUE: Should we allow blocked to be fired here too, if waiting takes
> #    "too long"?
> #
> # 8. Delete db.
> http://dvcs.w3.org/hg/**IndexedDB/raw-file/tip/**
> Overview.html#dfn-steps-for-**running-a--versionchange--**transaction<http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-running-a--versionchange--transaction>
> # 4. Wait until either all objects in openDatabases are closed and all of
> #    their transactions are finished.
> #
> #    ISSUE: If .close() is called immediately but a transaction associated
> #           with the connection keeps running for a "long time", should we
> #           also fire a blocked event?
> #
> #    ISSUE: If, while we're waiting here, someone calls open with a
> #           version number higher than version, we should probably let
> #           that upgrade run first and bail here if it was successful.
> To be very honest, the whole blocked and then wait-system seems very over
> the top for a small benefit. IMHO the harm is greater than any potential
> small benefit. We'd have to keep lots of requests indefinitely open.
> If the other page having an open database doesn't clean up and db.close()
> in its db.versionchange handler, most definitely the developer haven't
> ever thought about the case. I see no benefit in waiting for that to
> happen. And the page that is being blocked, also has no way to abort/close
> its own request if you were to follow spec because transaction is not set
> until after blocked has run(!).

We've also received comments from internal development teams about this
issue.  The devs didn't like having an outstanding request that may or may
not ever receive a success event. They planned on cancelling their open
request if they got a blocked event but, as Odin points out, quickly
discovered there was no way to do so.  We've talked briefly about adding
something like IndexedDB.openOrFail("db", high_version) that would fire a
BlockedError if other open connections didn't close in response to
versionchange events.

So not only will the browser implementation sit around with a useless
> request (possible several as the page retries or the user opens up more
> windows) - but also the page itself can't be a good citizen and clean up
> for itself (well, as long as they forgot to close in versionchange).
> So in the case of being blocked, it would be nicer to have the new page
> open request (or delete) get an error event, maybe something like
> BlockedError. It can then show the user «Please close the other window and
> [retry]».
> Also, there's a much bigger chance of developers listening to error on the
> opening page, rather than blocked.

+1.  Replacing "blocked" event with an "error" event named BlockedError
would be an improvement.

> As for what implementations do now, based on the very simple tests I did,
> Firefox seems to follow the spec as if it was written based on that
> implementation (:P) - IE10 doesn't send fire a versionchange request at
> all, but it does do "blocked". So I guess IE would rather quickly run into
> compat problems. It does however fire the blocked event on the opening
> page, although it's not really useful for much as far as I can see.
> What do you think?
> PS: In *any* case, those issues should be resolved some way, I just think
> simplifying such a corner case would be very beneficial.
> --
> Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software,
> http://opera.com
Received on Thursday, 26 July 2012 22:00:51 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:44 UTC