W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

[whatwg] Declarative unload data

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 07 May 2012 11:32:50 -0400
Message-ID: <4FA7EB22.7040603@mit.edu>
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.

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

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.

> 1. The author doesn't have to use fiddly hacks to avoid their request
> getting killed as the page unloads.

Yes.

> 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.

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.

-Boris
Received on Monday, 7 May 2012 08:32:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:08 GMT