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

[Darin Fisher]

On Thu, Sep 17, 2009 at 4:05 PM, Maciej Stachowiak <mjs at apple.com> wrote:

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

I agree.  _but_ my point about javascript:void() not disturbing an existing
navigation is not specific to unload.  If I have a page that does AJAXy
things with a background iframe, I can still let the user click on anchors,
provided they have href="javascript:void(...do stuff...)".  Maybe no one
does that...



>
>
> 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.
>
>
Perhaps.  We're talking about the web platform, right?



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

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