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

[Brady Eidson]

On Sep 17, 2009, at 2:17 PM, Ojan Vafai wrote:

> On Thu, Sep 17, 2009 at 2:11 PM, John Abd-El-Malek <jam at google.com>  
> wrote:
> On Thu, Sep 17, 2009 at 2:09 PM, Darin Fisher <darin at chromium.org>  
> wrote:
> On Thu, Sep 17, 2009 at 12:52 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
> 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.
>
> These sites presumably did it to split the sleep calls across as  
> many handlers as possible to avoid hung script detectors.  If they  
> rewrite their pages to use one clean method, it seems they only need  
> to do it in one place.
>
> There a plenty of sites that only have a beforeunload handler and  
> have no reason to register an unload handler. If you're not  
> prompting the user to stay on the page, the two events are  
> essentially equivalent.

This is not true.

I couldn't test IE right now but for Safari, Opera, and Firefox, I  
just independently verified that:
-unload handlers prevent a page from going into the page cache.
-beforeunload handlers do not
-beforeunload handlers are called before a page is navigated away  
from, even when the page is going into the page cache.

So the key difference is that while an unload handler will *only* ever  
run once, when a page is destroyed, a beforeunload handler might run  
multiple times, each time the user navigates away from the page after  
returning to it.

This might not be immediately relevant to the conversation, but they  
are not the same and I'd rather the conversation not assume they are.

In practice, if an author uses beforeunload as their unload handler,  
they are doing The Wrong Thing(tm)

~Brady

>
> Ojan
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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