Re: [whatwg] pagehide for pages going in to the page cache (was "pagehide vs pagevis")

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

Received on Thursday, 30 May 2013 00:29:02 UTC