[webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)
mjs at apple.com
Thu Sep 17 16:05:51 PDT 2009
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>
> 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>
>> 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
>> would not interfere with an existing navigation.
>> 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
>> nit: WebKit and most browsers that I tested _only_ do so if the
>> 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:
> 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
> notice that it does not interrupt the existing navigation.
Navigation from unload handlers is buggy.
> 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
> in a string. Coincidence, really??
It seems like a bug that it's inconsistent between different ways of
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev