[webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[Maciej Stachowiak]

On Sep 16, 2009, at 10:47 PM, Darin Fisher wrote:

>
>
> By the way, to be clear these ads aren't on the critical path for  
> link clicks.  A navigation occurs, and the ad just observes unload.   
> During unload it presumably tries to send home some data (ad  
> impression time, perhaps?).  I'm not sure how a redirect could be  
> used to report such information.
>
> <a ping> is a useful tool nonetheless because you could dynamically  
> create one, and dispatch a click event to it.


OK, so it sounds like what these sites (or ad networks) want is  
departure auditing, not hyperlink auditing. It sounds to me like  
guaranteeing completion of I/O started in unload (without blocking the  
next page load) would be a better solution for this than <a ping>.  
Here's why:

1) What these sites want to do is not actually hyperlink auditing, so  
why make them use a strange workaround? Their desired outcome seems  
totally unrelated to the normal use of <a ping>.

2) Dispatching a click event manually to an <a> element is way more  
awkward than other ways of doing this, compare the following to the  
trivial new Image() one-liner:

      var link = document.createElement("a");
      link.href = "http://example.com/";
      link.ping = "http://ping-site.com";
      var evt = document.createEvent("MouseEvent");
      evt.initMouseEvent("click", true, true, window, 1, 0, 0, 0, 0,  
false, false, false, false, 0, null);
      link.dispatchEvent(evt);

3) Dispatching a click event to a manually created link link from an  
unload handler has weird and inconsistent results in current browsers:
     a) Dispatching a click event as outlined above works in Safari  
and Opera, but not in Firefox (even outside unload).
     b) Dispatching a click event as above in the unload handler  
crashes current Safari (oops! will file bug), actuates the hidden link  
in Opera resulting in navigation to yahoo.com, and does nothing in  
Firefox.

4) Per HTML5, clicking on an <a> element without an href does nothing,  
and activating a link with an href always actually follows the link,  
with no exception for the unload handler. Synthetic clicks are allowed  
to work, except in the case of frame targetting. So if all browsers  
did everything per spec, you couldn't use the "manually create <a  
ping>" trick without redirecting the navigation. As far as I can tell,  
per HTML5 there is no circumstance in which the ping is issued without  
also actuating a navigation.

The combination of these factors makes me think that <a ping> will not  
address the problem, and we should guarantee completion for I/O  
started in unload. The advantage is that if sites start the I/O before  
doing a busy loop, it will still work, so they'll have no incentive to  
start a busy loop arms race.

Regards,
Maciej