On May 30, 2013, at 11:34 AM, Boris Zbarsky <[email protected]> wrote:
> On 5/30/13 2:26 PM, Brady Eidson wrote: >>> So how does your setup differ in a way that actually makes this >>> impossible to implement? >> >> The design is that after pagehide returns, if the traversal is still >> taking place and the page is going into the cache, no further events >> take place. > > Yes, you said that already. But what exactly prevents, in your design, the > running of a visibilitychange handler between "pagehide returns" and "check > whether the traversal is still taking place and the page is going into the > cache”? It’s not a problem that the spec is asking us to dispatch the visibilitychanged event after “pagehide with persisted set to true.” It’s a problem that the spec expects the page to be able to handle it. There is nothing in our design that would prevent us from dispatching the event after “pagehide with persisted set to true” returns. But the event will never be observed. Like Gecko, we also dispatch unload to these pages. But it is never observed. We’ve always treated “pagehide with persisted set to true” as equivalent to “unload.” The design of our page cache is that once “pagehide with persisted set to true” returns the page is inert/suspended/paused/persisted/whatever you want to call it. It cannot receive events anymore. It is as if it had been unloaded. Which is why I brought up the hypothetical case of “This wouldn’t make sense after unload, would it?” ~Brady
