Re: [IndexedDB] blocked event could be an error

[Jonas Sicking]

On Mon, Oct 1, 2012 at 11:25 AM, David Grogan  wrote:
>
>
> On Thu, Sep 27, 2012 at 9:31 AM, Jonas Sicking  wrote:
>>
>> On Thu, Sep 27, 2012 at 6:47 AM, João Eiras  wrote:
>> >
>> >>>   http://odinho.html5.org/IndexedDB/spec/Overview.html
>> >>
>> >>
>> >> Like I said, I think it's too late to make such a big change. I
>> >> believe it's much too late to make such a change in IE10, and we have
>> >> been shipping Firefox with the current behavior for quite a while now
>> >> (and are about to unprefix with our current behavior).
>> >>
>> >> / Jonas
>> >
>> >
>> > Sorry but it is not late. It's actually quite early and the right time.
>>
>> I don't know by what measure it's "quite early" or "the right time".
>
>
> It'd be the right time because though IDB usage is picking up, it's still
> relatively low. Optimally this change would have been made a few months or
> years ago, but now is better than later.
>
>> We've passed Last Call, there are 3 shipping implementations, all of
>> which have considered their implementation complete enough to switch
>> from prefixed implementations to unprefixed ones. They all implement
>> the behavior that you are proposing to change.
>
>
> We'd be ok with changing this, our unprefixedness notwithstanding. I think
> the pain it would save developers down the road would make up for the
> immediate pain it would cause to both vendors and developers. But that's
> just a judgment call, I'm relying on intuition and obviously have no data
> about what the future will hold.
>
> To balance the concerns of open with complicated semantics and
> backward-compatibility, I propose that we add two methods to IDBFactory:
> openOrFail and openOrBlock.  Most introductory IDB tutorials and examples
> would steer developers towards openOrFail.  The current open method would be
> an alias for openOrBlock.  That open's documentation would be "[deprecated]
> alias for openOrBlock" should give developers some pause about using it just
> because it has the simplest name.

My perception is that it's too late for microsoft to change this for
IE10. I also know that developers will strongly prefer .open to
.openOrX purely based on the length of the name.

I think that leaves us with keeping .open as-is and adding a
.openOrFail function.

I'd be ok with doing that. If we do it for v1 or not I don't have a
strong opinion of.

/ Jonas

Re: [IndexedDB] blocked event could be an error

[David Grogan]

On Thu, Sep 27, 2012 at 9:31 AM, Jonas Sicking  wrote:

> On Thu, Sep 27, 2012 at 6:47 AM, João Eiras  wrote:
> >
> >>>   http://odinho.html5.org/IndexedDB/spec/Overview.html
> >>
> >>
> >> Like I said, I think it's too late to make such a big change. I
> >> believe it's much too late to make such a change in IE10, and we have
> >> been shipping Firefox with the current behavior for quite a while now
> >> (and are about to unprefix with our current behavior).
> >>
> >> / Jonas
> >
> >
> > Sorry but it is not late. It's actually quite early and the right time.
>
> I don't know by what measure it's "quite early" or "the right time".
>

It'd be the right time because though IDB usage is picking up, it's still
relatively low. Optimally this change would have been made a few months or
years ago, but now is better than later.

We've passed Last Call, there are 3 shipping implementations, all of
> which have considered their implementation complete enough to switch
> from prefixed implementations to unprefixed ones. They all implement
> the behavior that you are proposing to change.
>

We'd be ok with changing this, our unprefixedness notwithstanding. I think
the pain it would save developers down the road would make up for the
immediate pain it would cause to both vendors and developers. But that's
just a judgment call, I'm relying on intuition and obviously have no data
about what the future will hold.

To balance the concerns of open with complicated semantics and
backward-compatibility, I propose that we add two methods to IDBFactory:
openOrFail and openOrBlock.  Most introductory IDB tutorials and examples
would steer developers towards openOrFail.  The current open method would
be an alias for openOrBlock.  That open's documentation would be
"[deprecated] alias for openOrBlock" should give developers some pause
about using it just because it has the simplest name.

At least the Amazon cloud reader uses IndexedDB. I've started
> receiving enough questions about IDB that I would imagine that there
> are more websites deployed which uses it.
>
> / Jonas
>
>

Re: [IndexedDB] blocked event could be an error

[Jonas Sicking]

On Thu, Sep 27, 2012 at 6:47 AM, João Eiras  wrote:
>
>>>   http://odinho.html5.org/IndexedDB/spec/Overview.html
>>
>>
>> Like I said, I think it's too late to make such a big change. I
>> believe it's much too late to make such a change in IE10, and we have
>> been shipping Firefox with the current behavior for quite a while now
>> (and are about to unprefix with our current behavior).
>>
>> / Jonas
>
>
> Sorry but it is not late. It's actually quite early and the right time.

I don't know by what measure it's "quite early" or "the right time".
We've passed Last Call, there are 3 shipping implementations, all of
which have considered their implementation complete enough to switch
from prefixed implementations to unprefixed ones. They all implement
the behavior that you are proposing to change.

At least the Amazon cloud reader uses IndexedDB. I've started
receiving enough questions about IDB that I would imagine that there
are more websites deployed which uses it.

/ Jonas

Re: [IndexedDB] blocked event could be an error

[João Eiras]

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


Like I said, I think it's too late to make such a big change. I
believe it's much too late to make such a change in IE10, and we have
been shipping Firefox with the current behavior for quite a while now
(and are about to unprefix with our current behavior).

/ Jonas


Sorry but it is not late. It's actually quite early and the right time.

The spec is still a working draft, all uses so far of IDB online are  
either html5 benchmarks or tutorials/examples. So, nothing of importance  
will be affected,


Besides, this is a corner case.

Re: [IndexedDB] blocked event could be an error

[Jonas Sicking]

On Wed, Sep 5, 2012 at 9:54 AM, Odin Hørthe Omdal  wrote:
> David Grogan  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

Like I said, I think it's too late to make such a big change. I
believe it's much too late to make such a change in IE10, and we have
been shipping Firefox with the current behavior for quite a while now
(and are about to unprefix with our current behavior).

/ Jonas

Re: [IndexedDB] blocked event could be an error

[Odin Hørthe Omdal]

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

Re: [IndexedDB] blocked event could be an error

[Odin Hørthe Omdal]

On Fri, 27 Jul 2012 00:31:08 +0200, Jonas Sicking  wrote:


On Thu, Jul 26, 2012 at 3:28 PM, João Eiras  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 can very well be achieved by detecting the BlockedError, and  
adding a retry button which calls open() again.


If you really want a open() and wait forever behavior, that should not  
be the default one.


I'm not at all comfortable with changing the default behavior this
late in the process.


I really think we should change it. The behaviour we have now is very very  
surprising and I don't think very sane.


If the IE implementation that's available now really is the one they're  
shipping (I seem to remember they said something like that), it'll be  
divergent in those parts already.


The alternatives are not that good, they are papering over a problem so  
that careful developers can do the right thing, but they will probably  
also write  db.onversionchange = function() { db.close() }  correctly. The  
careless developers (of which inhabit many parts of the intertubes) will  
not, and then you'd just get all those waiting requests hanging around.



If someone wants to tell me to close my other window, it's very easy to  
check the error on the open request for BlockedError. Of course, if you  
want it to be automatic, you'd have to try a new open with some interval,  
but that shouldn't be a big problem.



I would go out on a limb and say that I think this part of IndexedDB is  
probably not very much used at this point. And if there are any users,  
they're hopefully already sufficently advanced to already have written a  
db-close in versionchange so that they won't be relying on the blocked  
system.



Well, it's a lot of hope, but I don't think this is something we should be  
stuck with.

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

Re: [IndexedDB] blocked event could be an error

[Jonas Sicking]

On Thu, Jul 26, 2012 at 3:28 PM, João Eiras  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 can very well be achieved by detecting the BlockedError, and adding a
> retry button which calls open() again.
>
> If you really want a open() and wait forever behavior, that should not be
> the default one.

I'm not at all comfortable with changing the default behavior this
late in the process.

/ Jonas

Re: [IndexedDB] blocked event could be an error

[João Eiras]

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 can very well be achieved by detecting the BlockedError, and adding a  
retry button which calls open() again.


If you really want a open() and wait forever behavior, that should not be  
the default one.

Re: [IndexedDB] blocked event could be an error

[Jonas Sicking]

On Thu, Jul 26, 2012 at 2:59 PM, David Grogan  wrote:
>
>
> On Mon, Jul 23, 2012 at 11:49 AM, Odin Hørthe Omdal 
> 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
>>
>> # 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
>>
>> # 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.

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.

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.


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.

/ Jonas

Re: [IndexedDB] blocked event could be an error

[David Grogan]

On Mon, Jul 23, 2012 at 11:49 AM, Odin Hørthe Omdal 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
>
> # 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
>
> # 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
>
>

[IndexedDB] blocked event could be an error

[Odin Hørthe Omdal]

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

# 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

# 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(!).

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.



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