Re: [IndexedDB] blocked event could be an error

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
>
>