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 <[email protected]>
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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
