[whatwg] Declarative unload data

[Ian Hickson]

On Mon, 7 May 2012, Tab Atkins Jr. wrote:
>
> Besides those annoying "Are you sure you want to leave this page?" 
> dialogs, the primary use of the unload events is a final, desperate 
> attempt to throw a message at the server, either to save some data or 
> release some server-held resource.

Do you have any examples of these I could study?

How do they handle the user just closing his laptop and walking away, or 
being on the phone and switching to a non-browser app, or entering a 
tunnel and losing signal, or the browser crashing, or the user forgetting 
to pay his bills and getting cut off by the ISP, or the user leaving the 
tab open for five weeks before coming back to it, or the user's house 
catching fire and the computer melting, or the user opening up multiple 
copies of the tab with the same Web app and then closing the first one, 
or if the user closes the tab by mistake and then reopens it?


> However, this is tricky to do reliably, because browsers kill pending 
> XHRs as they unload the page. Right now, I think the most reliable 
> method is to create an <img> and set its @src, because of an old quirk 
> in IE that other browsers have copied which means that pending image 
> loads are carried to completion rather than being killed.

(Incidentally, this isn't specced currently; if anyone has any test cases 
demonstrating this, please do file a bug so I can spec it.)


> Can we fix this?

It's not entirely clear to me that it's a problem. :-)

If the app just wants to save user data, the app can just show an 
indicator of what data has been saved, or when data was last saved, or 
whether there is unsaved data, with an explicit "save now" control when 
there is unsaved data, and then save everything else asynchronously as it 
is modified. This is then resilient to the events described above.

If the app has server-side resources, then it's probably best to just keep 
them around on a timeout, bringing them back if the page returns from the 
dead, so that long-lived tabs don't waste resources, so that suddenly 
suspended tabs don't waste resources, and so that tabs that are closed and 
then resumed don't need to waste time getting the resources back.

(Having said that, another way to do this is just to hold a TCP connection 
open (e.g. using WebSocket or an <iframe>), and then doing the cleanup on 
the server side when the connection dies.)


> var foo = new unloadHandler('http://example.com/ajax');
> foo.data = "bar"
> /* Now, if the page ever gets unloaded, you're guaranteed that
> "http://example.com/ajax" will eventually get a request with the value
> "bar". */
> 
> Presumably you'd be able to set other relevant XHR properties, like 
> un/pw and get/post and such, on the unloadhandler object.

This seems like a very close relation to XMLHttpRequest. My suggestion 
would be that if we want to implement this, we implement it as a feature 
of XHR, e.g.:

   var foo = new XMLHttpRequest({ autoSendOnUnload: true });
   foo.open('GET', 'http://example.com/ajax');
   foo.addData('bar');

...or some such.

So I'm punting this over to Anne.


But before we spec this, I think we should make sure that there's browser 
vendors who want to implement it. The thread (which I haven't quoted here) 
raised a number of serious concerns about whether it would be a good idea.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'