[whatwg] pagehide for pages going in to the page cache (was "pagehide vs pagevis")
Boris Zbarsky
bzbarsky at MIT.EDU
Wed May 29 17:28:32 PDT 2013
On 5/29/13 4:27 PM, Brady Eidson wrote:
> Does Mozilla have a test for this that I could explore in WebKit?
It's pretty trivial to create a testcase. Something simple like this:
test1.html:
<div onclick="window.test2 = window.open('test2.html')">Click me to open
a window, then follow the instructions in that window</div>
<hr>
<div onclick="window.testDiv.textContent = 'We modified the cached DOM';
window.testDiv.dispatchEvent(new Event('foo'));
alert(window.result);">Click me to dispatch an event</div>
test2.html:
<div id="target"></div>
<script>
var target = document.getElementById("target");
var parentWin = window.opener;
parentWin.testDiv = target;
target.addEventListener('foo', function() { parentWin.result = 5; });
</script>
<a href="http://www.example.com">Click this link, and then click the
"click me to dispatch an event" text in the opener. Then click the back
button.</a>
In Gecko, what happens is that the event listener is not fired, but the
DOM modification is also not shown after going back: attempts to do that
sort of thing discard the document from the page cache so you don't get
weird behavior where a document is acting unloaded but then suddenly
acts loaded.
In WebKit it looks like the page can be modified and then restored but
events don't fire on it while it's being modified or anything like that.
> If so, I can say that the design goals for your page cache and ours are radically different.
Yes, the design goals are almost certainly radically different. Our
page cache will discard on various attempts to modify the state of the
cached document; its existence is meant to be largely transparent to
pages, so modifying the document after unloading will in fact make sure
it's unloaded.
-Boris
More information about the whatwg
mailing list