[whatwg] pagehide vs pagevis

Boris Zbarsky bzbarsky at MIT.EDU
Thu May 30 10:31:34 PDT 2013

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).

> 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 sounds like you're arguing it should be "hidden", right?

> 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?

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.


More information about the whatwg mailing list