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

[Darin Fisher]

On Wed, Sep 16, 2009 at 11:46 PM, Maciej Stachowiak <mjs at apple.com> wrote:

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

For <a ping> to be used as I suggested, you would need to set the href to a
javascript URL such as javascript:void(), so that it would not interfere
with an existing navigation.  I think it would also be necessary for the
ping to be sent during the default event handler instead of when the href is
normally processed.

As for guaranteeing completion of I/O started during unload, I am fairly
concerned about the code complexity that would result from allowing some
resource loads to go uncanceled at page navigation time.  Pings are
different since they are fire and forget, but other resource loads, which
normally get read and processed by the frame / loader system are a bit
problematic to keep active.  We'd want to put them in a special mode where
they don't get canceled but also don't get processed when their responses
arrive.  There may be a clean way to do this, but I am concerned about the
potential maintenance cost due to the extra mode for resource loading.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090917/4d53c6f0/attachment.html>