- 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