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

[John Abd-El-Malek]

On Thu, Oct 15, 2009 at 12:31 AM, Darin Fisher <darin at chromium.org> wrote:

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

Does this argue for making the image loading trick work all the time from
JS, not just from unload handlers?  I tested with IE and it looks like the
image trick works all the time, not just in unload handlers.  My test case
was to load the image in the onload handler and change document.location to
"about:blank" right after.  Firefox/Safari/Chrome didn't load the image most
of the time.

I see your points about window.sendPing.  I think it's the most elegant
solution.  But given that we'll allow the image trick for pragmatic reasons,
then it's not needed.  Shouldn't the bar for exposing methods be high, i.e.
only if there's no other way of doing this?


>
> 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/91017f8c/attachment.html>