[whatwg] Declarative unload data

[Tab Atkins Jr.]

On Mon, May 7, 2012 at 5:32 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 5/7/12 3:53 AM, Tab Atkins Jr. wrote:
>> A page can set up an unloadHandler immediately on loading, and just
>> keep its .data property updated over time.  The author is then secure
>> in the knowledge that, barring complete computer destruction, if the
>> user shuts down their browser the server will receive a message with
>> whatever .data held at the time.
>
> Where "complete computer destruction" includes "browser crash" and several
> similar things?  I don't think that it's reasonable to require the browser
> to send the request after the browser process has exited: for one thing the
> browser may not have access to non-volatile storage at all.

Sure, that's pretty much a QoI issue.  We basically would just require
that it work on a clean unload, and allow browsers to make it work on
other types of "unloading".


> Presumably the request involved would never do any prompting for
> credentials; if they're needed it would fail?

Yes, definitely (unless you set .withCredentials on it or something,
like the XHR attribute).


> Also presumably the browser would be allowed to kill the connection once it
> receives the first response packet, instead of having to download all the
> response data?  That would be a win from the browser's point of view.

Yup, the response won't ever be seen by the page, so you can
immediately drop the connection once you've received enough of a
response to confirm that the server got it.


>> 2. The browser can go ahead and kill the page immediately, and send
>> the request at its leisure.
>
> I guess that's true if "bar" is converted to a string at foo.data set time.

Yes, I'd thought of that, but didn't mention it.  You definitely want
to do eager stringification.  Maybe do structured clone, as that
resolves getters?  (Right now that's equivalent to "eager JSON
stringification".)


> A bigger question is whether browsers really want to make it easier to do
> this or work on getting rid of the ability to phone home at/after unload
> altogether.  My gut reaction every time I see pages doing it is that they're
> up to no good, and code inspection usually indicates that I'm right: the #1
> use of this is for persistent user tracking.

That might be, but we won't be *stopping* anything then.  They can
instead, say, switch to just sending requests every 20s or something -
if they were measuring session duration you still get good accuracy,
but the total number of requests doesn't go up too much.  If they're
going to do this anyway, I'd prefer they do it in a way that's the
least intrusive and battery-draining, which unloadHandler does.

The legitimate use-case of doing a final info-squirt at the server to
save state is reasonable, though, and can't be done well as a
regularly-timed request - if you're doing one every 20s, you'll on
average lose the last 10s of activity the user has done, which can
suck.

~TJ