[webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)
jam at google.com
Thu Oct 15 10:39:26 PDT 2009
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
> Do we have agreement on proceeding with implementing the Image based
> 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>.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev