[whatwg] pagehide vs pagevis

[Brady Eidson]

On May 30, 2013, at 10:31 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 5/30/13 1:04 PM, Brady Eidson wrote:
>> Correct.  Of course note that pages that have been placed in the page
>> cache that are evicted have no visibility that the eviction occurred (at
>> least in WebKit)
> 
> I believe this is also true in Gecko.
> 
>> Let me ask you this - Are there any (reasonable) pages in the wild that
>> (reasonably) expect to do anything *after* the unload event is fired?  I
>> would say no, probably not.
> 
> It depends on what you mean by "do" and "after".  Pages expect certain network requests to outlive the unload event, for example, for various phoning-home stuff and break horribly if you disable that (we tried, and found it to not be web-compatible).

Sure - Certain classes of activity started within the unload handler have to outlive it.  What I meant was “run scripts after their unload event handler has returned”

>> If a page listens to pagehide instead of unload, then they are not
>> reasonably expecting to do anything after "pagehide with persisted set
>> to false” is fired.
> 
> This again depends on what "do" means, but ok.
> 
>> Would it have made sense for page-vis to put the visibilitychanged event
>> *after* unload?  I don’t think so.
> 
> I think we agree on that.
> 
>> So I still cannot see how having it after "pagehide with persisted set
>> to false” is the right call.  Maybe authors writing to the spec might
>> expect it, but they wouldn’t find it very useful.
> 
> Here's a question.  What should the visibilityState be while pagehide is firing?  Should it be "visible" or "hidden", if the page is in a foreground tab?

It should be whatever it is while the unload event is firing.

> It sounds like you're arguing it should be "hidden", right?

If it is “hidden” while the unload event is firing - and my reading of the spec suggests that it is - then yes that’s what I’m arguing.
> 
>> The long standing design goals and implementation of our page cache
>> prevents us from delivering these events to a page that was just sent
>> “pagehide with persisted set to true”.
> 
> Even if it's not going into the page cache?

If persisted is set to true, then the page is going into the page cache.

If the pagehide handler does anything that prevents the page from going into the page cache, then that activity would also inherently prevent visibilitychanged from being observed.  (This is true in WebKit, I should clarify).

> It's pretty simple, at least in Gecko, to have a page which gets "pagehide with persisted set to true" and then "unload", if the pagehide handler does something that prevents the page from being cached after all.

In WebKit, if you have an unload handler, you don’t go into the page cache.

Therefore if you have an unload handler, you never get "pagehide with persisted set to true”

This was true at one time in Gecko also (per https://developer.mozilla.org/en-US/docs/Using_Firefox_1.5_caching) - Has that changed?  I couldn’t find documentation of such a change.

~Brady

> 
> -Boris