[webkit-dev] Back/forward cache for pages with unload handlers

[Brady Eidson]

On Sep 15, 2009, at 10:42 PM, Darin Fisher wrote:

> I'm very confused by this change.

I hoped to blog about the motivations shortly after landing the  
change, but today has been crazy.  Tomorrow I'll get something up  
explaining in detail why we're exploring this.

> If a page has an unload handler, then Firefox does not put the page  
> in the bfcache.

Correct - nor does Opera, nor did WebKit on Mac/Windows before  
r48388  ;)

> So the author of a page that has an unload handler would have no  
> reason to include a pagehide handler.

pagehide and unload are so painfully close to indentical, its easy to  
confuse what sets them apart.  You're correct that it's pointless to  
have both, but an author who is using unload has every reason to use  
pagehide *instead* when it is supported.

Mozilla created pagehide/pageshow because of the very problem we're  
trying to solve.  Per https://bugzilla.mozilla.org/show_bug.cgi?id=407125#c4 
  :
"pagehide/pageshow fire whenever unload/load would have fired before  
bfcache existed."

In other words, pagehide/pageshow are unload/load 2.0.  They are like  
unload/load but also let you go into the page cache.  In browsers  
where pagehide exists, unload is basically "pagehide, but also opting  
into slow navigation mode."

And we all should despise that!

> Does this change mean that unload handlers are never run?

Yes.  This is clearly the controversial part of this experiment, and  
why we've limited it to our mainline Mac and Windows ports.

Any other port is welcome to join in by enabling the  
PAGE_CACHE_ACCEPTS_UNLOAD_HANDLERS #define near the top of  
FrameLoader.cpp for their build.

> Or, are they run while the page is hidden (once it is evicted from  
> the page cache)?

This is something that is definitely worth exploring, and that we've  
discussed around the office, but that presents its own problems.

> I have to say, this seems like a big compatibility bug to me.

And to us - which is why we're running this experiment in WebKit  
nightlies and why I hope to get feedback on the impending blog post  
(stay tuned!) from web developers.

I perceive the worse case outcome of the experiment to be that we  
change the behavior back, but we will have educated web developers  
about pagehide and evangelized at least a few of them into switching  
over.

> What happens if the page has a beforeunload handler?

This behavior has not changed.  beforeunload events have always been  
able to stop a navigation before the page cache comes into play.

~Brady


> -Darin
>
>
> On Wed, Sep 9, 2009 at 4:07 PM, Brady Eidson <beidson at apple.com>  
> wrote:
> Since the beginning, WebKit has excluded pages with unload handlers  
> from its back/forward cache.  There has been an unspoken assumption  
> for 6 years now that we "have to do it."
>
> In recent explorations to improvements we can make to the back/ 
> forward cache, we've collected tons of data that suggests:
> -It would be a huge win for end users to remove this restriction, as  
> many pages are excluded from the page cache because they have unload  
> handlers.
> -Many are designed to do the same work in the pagehide handler under  
> Firefox.
> -Many of these unload handlers don't do anything actually important.
>
> In our quest to make WebKit better for end users, we'd like to  
> explore removing this limitation.  We would like to encourage  
> developers to use pagehide in WebKit now that we support it, and we  
> won't know if anything truly important breaks until we try it.  I  
> intend to land a patch removing the restriction sometime tomorrow.
>
> If anyone needs to keep it working for their port, please comment in  
> the bugzilla before then, as I don't mind one bit #ifdef'ing it so  
> it only affects the main Mac/Windows ports:
> https://bugs.webkit.org/show_bug.cgi?id=29021
>
> Thanks,
> ~Brady
> _______________________________________________
> 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/20090915/99f411a7/attachment.html>