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

[Darin Fisher]

On Wed, Oct 14, 2009 at 7:53 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Oct 14, 2009, at 6:43 PM, John Abd-El-Malek wrote:
>
>  To resurrect this thread.  I'm looking in implementing some of the methods
>> that we discussed so that web developers have no excuse in simulating sleeps
>> in unload handlers.
>>
>
> ...
>
>  -Image trick (image loads started from unload handlers outlive the page):
>> simple, maintains comparability with IE and existing sites.  however a
>> little inelegant and requires JavaScript.
>>
>
> ...
>
>  Do we have agreement on proceeding with implementing the Image based
>> approach?
>>
>
> Yes, I think we should let image loads from unload handlers run to
> completion. I don't see much downside, and the compatibility with IE
> behavior is pretty compelling.
>
> The other ideas you mentioned don't seem as good. Making a new API or a new
> XHR flag would be WebKit-specific and thus inferior to the Image thing. And
> I think <a ping>, though it may have its uses, does not apply to this use
> case. Dynamically creating an <a> element and sending it a fake click event
> is rather awkward. And navigations initiated from the unload handler do not
> actually happen. It would be weird to special-case things so that the ping
> is sent anyway, even though the navigation does not go through. Let's
> reserve <a ping> for hyperlink auditing and not bend it to the purpose of
> page close auditing.
>
> Regards,
> Maciej
>
>

I'm mostly convinced that we should implement the image hack.  I'm also
convinced that <a ping> is best left for hyperlink auditing.

However, if we do implement <a ping> (and I think we should), it seems
natural to also provide a scriptable way to produce a similar effect.
 window.sendPing seems attractive for that reason.

The way I look at it is, if a UA were to provide an option to disable pings,
should that option impact the behavior of the image hack?  It is clear from
the point of view of the web developer that <a ping> and window.sendPing
would be effected, but it is less clear in the case of the image hack.
 Maybe someone is using the image hack to prefetch images (a login screen
might prefetch resources for what lies behind the login screen), which is a
very different use case from sending pings.

If we do not do window.sendPing, then it also means that some people may be
tempted to create unload handlers just so that they can take advantage of
the image hack to send pings for things like usage data, when they would
otherwise just send the pings at their convenience (periodically perhaps).
 That seems rather awkward to me and unfortunate since it would be nice if
people didn't have to write unload handlers ;-)

Anyways, this is just a minor point.  Overall, I'm happy even if we only
implement the image hack and <a ping>.  It just seems like there is a
reasonable case for window.sendPing.

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