Re: [whatwg] SQL storage and onunload
It seems to be a natural idea to save Web application state from an unload event handler. But is it guaranteed that client-side database API is still functional at this point? And if it is - can one queue up more statements and/or transactions from statement callbacks? I see two options here: 1. Delay leaving the page indefinitely, until all outstanding database operations have completed. 2. Leave the page immediately, canceling all outstanding database operations. Option #1 seems undesirable because it allows a malicious or poorly programmed website to hijack the browser. That's a pretty bad user experience -- one that the database API's asynchronous callbacks were specifically designed to avoid. Option #2 is not ideal, but it's workable. A beforeunload event handler can detect unsaved changes and prompt the user to cancel the navigation and save. Once the save succeeds, the page can update its UI to indicate that navigation is OK. So, I recommend option #2. Geoff On Feb 8, 2008, at 1:44 AM, Alexey Proskuryakov wrote: There needs to be some limits put on this, as otherwise a script could continue to use resources indefinitely after a browser window is closed. But I do not see where it is specified, explicitly or implicitly. - WBR, Alexey Proskuryakov
Re: [whatwg] SQL storage and onunload
On Sat, 09 Feb 2008 22:06:39 +0100, Alexey Proskuryakov [EMAIL PROTECTED] wrote: On Feb 9, 2008, at 12:58 PM, Anne van Kesteren wrote: As far as the unload handler question, what are the semantics for XHR? I think the user leaving the page is the same as aborting the download. I've seen servers (e.g. Google) use XHR in onunload to track usage statistics. Sounds like a reasonable use case (really, is there a better way?). How do you determine when you can end the process? It also seems kind of icky that the window is already closed (as far as the end user is concerned), but that code is still executing on behalf of it. Could be that I misunderstood something though. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] SQL storage and onunload
On Fri, 08 Feb 2008 18:24:58 +0100, Brady Eidson [EMAIL PROTECTED] wrote: As far as the unload handler question, what are the semantics for XHR? I think the user leaving the page is the same as aborting the download. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] SQL storage and onunload
On Feb 9, 2008, at 12:58 PM, Anne van Kesteren wrote: As far as the unload handler question, what are the semantics for XHR? I think the user leaving the page is the same as aborting the download. I've seen servers (e.g. Google) use XHR in onunload to track usage statistics. Sounds like a reasonable use case (really, is there a better way?). - WBR, Alexey Proskuryakov
[whatwg] SQL storage and onunload
It seems to be a natural idea to save Web application state from an unload event handler. But is it guaranteed that client-side database API is still functional at this point? And if it is - can one queue up more statements and/or transactions from statement callbacks? There needs to be some limits put on this, as otherwise a script could continue to use resources indefinitely after a browser window is closed. But I do not see where it is specified, explicitly or implicitly. - WBR, Alexey Proskuryakov
Re: [whatwg] SQL storage and onunload
Though it would be very nice to have defined semantics wrt the unload handler, I always thought this work could be done with the beforeonunload handler, instead. As far as the unload handler question, what are the semantics for XHR? Seems the application of saving some application state via I/O is the same concept here, so the same rules should apply. ~Brady On Feb 8, 2008, at 1:44 AM, Alexey Proskuryakov wrote: It seems to be a natural idea to save Web application state from an unload event handler. But is it guaranteed that client-side database API is still functional at this point? And if it is - can one queue up more statements and/or transactions from statement callbacks? There needs to be some limits put on this, as otherwise a script could continue to use resources indefinitely after a browser window is closed. But I do not see where it is specified, explicitly or implicitly. - WBR, Alexey Proskuryakov
Re: [whatwg] SQL storage and onunload
On Feb 8, 2008, at 8:24 PM, Brady Eidson wrote: Though it would be very nice to have defined semantics wrt the unload handler, I always thought this work could be done with the beforeonunload handler, instead. I am not sure if this helps much - you can create a transaction from onbeforeunload, but you are likely to run the actual statement after the frame closes. As far as the unload handler question, what are the semantics for XHR? Seems the application of saving some application state via I/ O is the same concept here, so the same rules should apply. That's a good question :) - WBR, Alexey Proskuryakov
Re: [whatwg] SQL storage and onunload
On Feb 8, 2008, at 9:44 AM, Alexey Proskuryakov wrote: On Feb 8, 2008, at 8:24 PM, Brady Eidson wrote: Though it would be very nice to have defined semantics wrt the unload handler, I always thought this work could be done with the beforeonunload handler, instead. I am not sure if this helps much - you can create a transaction from onbeforeunload, but you are likely to run the actual statement after the frame closes. Not if your beforeonunload handler prevents the frame from closing, and you continue to prevent it from closing until your data is saved! As far as the unload handler question, what are the semantics for XHR? Seems the application of saving some application state via I/ O is the same concept here, so the same rules should apply. That's a good question :) That I've never seen a good answer to! =D ~Brady - WBR, Alexey Proskuryakov
