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
