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

[John Abd-El-Malek]

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

Sounds good.  I'll start the image loading first, and then when I'm done I
can do <a ping>.


>
> Regards,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091015/8e1d2ba9/attachment.html>