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

[John Abd-El-Malek]

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.
>From this thread, the options that were discussed were
-<a ping>: The pros were that it would work without JavaScript, and could be
disabled easily via an option like referral headers.   But given that it's
not possible for this to work in iframes in Firefox and perhaps other
browsers and that the users of the sleeps are ad networks using iframes, it
doesn't fit the requirements.
-window.sendPing(): elegant, but requires educating web developers.  also
required JavaScript to be enabled.
-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.
-allow XHR with a special flag, or ones started from unload handlers to
outlive the page: doesn't seem worth it since it involves both extra
complexity in WebCore, requires changing web sites, and doesn't have
compatibility with IE

In an ideal world, I would prefer window.sendPing.  Given the benefits of
maintaining compatibility with IE and existing sites, I do think the image
loading trick is the best solution at this point.  I've  gone back and forth
on this a few times, but at the end the limitations of <a ping> where it
does not work for iframes in other browsers render it useless.  Although the
image trick requires JavaScript, I think this is acceptable since the
problem sites now already use JavaScript to simulate sleeps and fetch the
image, so we're not placing more requirements on them.

Do we have agreement on proceeding with implementing the Image based
approach?

Thanks,
John

On Thu, Sep 17, 2009 at 6:26 PM, John Abd-El-Malek <jam at google.com> wrote:

>
>
> On Thu, Sep 17, 2009 at 4:08 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Sep 17, 2009, at 2:16 PM, John Abd-El-Malek wrote:
>>
>>
>>>
>>> I think the image trick is more attractive than <a ping> because it's
>>> easier for web developers to use.  But I'm not convinced it's the cleanest
>>> method we can come up with.  If we are expecting web developers to change,
>>> then I'd prefer something more explicit link asyncPing(url).  The benefit is
>>> that it doesn't tie up connection limits like image loading would, and hence
>>> shouldn't impact the navigated page's loading.  The UA is then free to pick
>>> the best time to do the ping, i.e. when network activity has died down.
>>>
>>>
>> With the Image trick, web developers don't have to change, other than to
>> get rid of the busy loop. I wouldn't be too averse to also adding an
>> explicit  ping API, but it seems to me it's possible to do many of the
>> optimizations you describe for the Image-in-unload trick.
>>
>
> Good points.  These were my biggest sticking point with the image trick,
> now that I'm not concerned about them anymore, I really appreciate the
> compatibility with IE that this gives.
>
>
>>
>>  - Maciej
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091014/f64a0e55/attachment.html>