Re: [IndexedDB] blocked event could be an error

David Grogan <dgrogan@chromium.org> wrote:
> Odin wrote:
>> 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.

I did this. Proposed patch to the spec is here:

       http://odinho.html5.org/IndexedDB/spec/blocked.patch


If you are not super proficient reading patches but prefer to see the
result, I have the file I used to produce the diff here:

       http://odinho.html5.org/IndexedDB/spec/Overview.html



Jonas Sicking <jonas@sicking.cc> wrote:
> I definitely think that we need to keep the "blocked" events as
> non-error events since it supports the use case of opening a
> connection and displaying UI to the user asking that other tabs are
> closed if the "blocked" event fires.

That is easily doable either way. You'll just do:

       var openrq = open('db', 2);
       openrq.onerror = function(e) {
           if (e.target.error.name == "BlockedError")
               show_blocked_ui();
           }
       };

> However the use cases brought up here makes sense. I think we can
> solve this in two ways:
>
> Add a .abort() method to IDBOpenDBRequest. This would cause an "error"
> event to be fired immediately (but asynchronously) and the attempt to
> open the database to be canceled.
>
> Add a openOrFail method in addition to the existing open method.
> openOrFail would automatically abort the attempt to open the database
> as soon as "blocked" is fired. Instead an "error" event would
> immediately be fired.

They both expand the API-surface and put the responsibility of doing the
correct thing in the web author's hands. Whereas the functionality we're
retaining in the old open() is of very dubious value - and should probably
never be used (so why keep it?).

With openOrFail, the easiest, nicest and most straight forward solution is
the wrong one (open). The behavior you wrote for openOrFail is what I've
done in the patch, only with the name "open".

> However is this something that we can wait with until v2? Punting
> something to v2 doesn't mean that implementation needs to hold off
> implementing until v2 is "finished", but it means that we should start
> an official v2 draft sooner rather than later.
>
> I don't have a strong opinion either way.

I'd like for us to avoid having to implement the blocked behavior as it is
now. I think the web compat story of it is so good that it would be a
change we could very easily do.


Rockstar web dev "Tim" has read the spec, and thus he will have a
versionchange handler in his page already:

       conn.onversionchange = function() { conn.close() };

So since he already has a versionchange event handler that closes the
connection, there is actually *no change* whatsoever. The only behavior
change this introduces is when newbie web dev "John" doesn't close his
connection when getting a versionchange event.

And being a newbie, like John is, he is also only listening for the error
event, because the tutorial he followed left out the most specialized
advanced stuff that's not really needed for normal use.

There's one change John should do to his code though, and that is moving
the code in the blocked handler on the open request to instead be inside
an if "BlockedError" test in the error handler. Anyway, that handler will
probably not be run because the versionchange is closing the connection as
it should. So it isn't really hurting all that much if he keeps it there.


As I said earlier, Internet Explorer is also helping us make this change.
It's hardest for them to make a change, but since that they actually don't
implement what the spec say in this area, they luckily don't have any
working code to change anyway. :-)



A small added benefit is that it makes the spec a few characters shorter,
and shrinks the API-surface a bit ;-)

-- 
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com

Received on Wednesday, 5 September 2012 16:55:18 UTC