Re: [whatwg] pagehide vs pagevis

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.

-Boris

Received on Thursday, 30 May 2013 17:32:09 UTC