- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 22 Apr 2013 13:17:40 -0400
- To: public-webapps@w3.org
On 4/22/13 12:47 PM, Tab Atkins Jr. wrote:
> As long as you don't spin the event loop
That's tricky. Here's some simple code at global scope:
request = indexedDB.open('database');
request.onsuccess = function () {};
Can that code spin the event loop between the open() call and the
onsuccess setter being invoked?
Sure: all it takes is someone defining a setter for "request" on the
window that just saves the given value and a getter for "request" that
calls showModalDialog to ask the user whether to allow the get and then
returns the saved value.
Now why someone would do that, I have no idea, but that's true for a lot
of things people do in practice in websites. ;) My point is that
whether the event loop spins is a very non-local property of the code.
It's annoying to have to depend on such things.
Is there a reason to not pass the success/error/upgradeneeded callbacks
in a dictionary to open() in this case, so that the request object is
born with the right bits and the actual reques it not kicked off until
_after_ the side-effects of getting them off the dictionary have fully
run to completion?
> This... is precisely the sort of thing that you shouldn't do. Just
> don't do this, and you're golden.
I don't believe you are; see above.
> The "request.execute()" is more or less implied by hitting the bottom
> of your function, when it returns control back to the browsers.
We wish; see above.
-Boris
Received on Monday, 22 April 2013 17:18:15 UTC