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

[Maciej Stachowiak]

On Sep 17, 2009, at 2:09 PM, Darin Fisher wrote:

>
>
> On Thu, Sep 17, 2009 at 12:52 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>
> On Sep 17, 2009, at 12:14 PM, Darin Fisher wrote:
>
>>
>>
>> On Thu, Sep 17, 2009 at 2:28 AM, Maciej Stachowiak <mjs at apple.com>  
>> wrote:
>>
>> On Sep 17, 2009, at 12:35 AM, Darin Fisher wrote:
>>
>>
>>
>> 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.
>>
>> Navigating to a javascript: URL will still cancel with an existing  
>> pending navigation, both per spec and in at least some browser  
>> engines (including WebKit). For spec reference see step 5 here: <http://dev.w3.org/html5/spec/Overview.html#navigate 
>> >. Note lack of exception for "javascript:" URLs.
>>
>> nit: WebKit and most browsers that I tested _only_ do so if the  
>> javascript: URL evaluates to a string. Take a look at  
>> FrameLoader::executeIfJavaScriptURL().  I can also share my test  
>> case with you if you are still doubting! ;-)
>
> My test case did this from an onclick handler, and the navigation to  
> yahoo.com did not happen:
>
>      location.href="http://yahoo.com/";
>      location.href="javascript:void()";
>
>
> Yes, in that case the scheduled location change from the first href  
> assignment is cancelled by the second.
>
> My test case was to dispatch a click event to an anchor tag during  
> the unload handler.  Set the anchor's href to javascript:void() and  
> notice that it does not interrupt the existing navigation.

Navigation from unload handlers is buggy.

>
> It may be that other ways of navigating to a javascript: URL don't  
> stop a pending load, but that would be a bug.
>
> I'm not sure.  It seems like each browser goes out of its way to  
> only cancel the existing navigation when the javascript: URL results  
> in a string.  Coincidence, really??

It seems like a bug that it's inconsistent between different ways of  
navigating.

>
>
> Based on your comments below, I think the expedient thing to do is  
> to let Image loads (only) complete their I/O when initiated from  
> unload or pagehide.
>
> Why exclude beforeunload?  Some of the sites we found use the busy  
> loop hack in beforeunload.

I wasn't deliberately excluding it. Including beforeunload seems fine.

Regards,
Maciej

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