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
