Re: [whatwg] pagehide vs pagevis

On May 29, 2013, at 5:34 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 5/29/13 4:30 PM, Brady Eidson wrote:
>> I see in the HTML spec that the step *before* firing pagehide is “set
>> the Document’s page showing flag to false,” but I can’t find language
>> that says pagehide fires *before* the page is actually hidden, and
>> unload fires *after* the page is actually hidden.
> 
> Hidden in terms of "document.hidden" or something else?

Hidden as in “visible” in the concept of “page visibility” and “visibilitychanged"
> 
>> pageshow is a history traversal event, and not a visibility event.  I
>> don’t see a guarantee in any spec that “pageshow” comes after the
>> document is actually visible.
> 
> It comes after it's visible in terms of document.visibilityState, for pages not in background tabs.

This is true *only* because you and the other people who worked on integrating page-vis into HTML decided it was true.

What I meant was that the pageshow event does *not* inherently mean that the page is actually visible - actually has pixels painted on the screen.  Whereas the visibilitychanged event would (presumably?) only fire once the pixels are painted on the screen.

> Obviously for pages in background tabs the visibilityState of the document is just hidden throughout.

Sure.

> 
>> First, since pagehide currently always has persisted set to true (in the
>> spec and in Gecko)
> 
> This is false in Gecko.  There are lots of cases in which persisted is not set to true in pagehide.  It's only set to true if the page is in fact going to be placed in the page cache based on the information available at the point pagehide fires.
> 
> The spec on setting "persisted" in the pagehide event is just wrong.

I suppose I jumped to an assumption on Gecko, my apologies.  I definitely agree the spec on pagehide is just wrong.

> 
>> Third, is the difference between 4 states and 5 states really appreciable?
> 
> Which states are 4 and 5?
> 
> In any case, there are multiple page visibility implementations shipping now, with interop on the ordering last I checked, and the spec is finalized.  If you want to change around how it works, you're going to have to convince all the people who are already shipping implementations of it as written, apparently with no problems, to change behavior...

Only people without page caches or with a gecko-style page cache could ship this.

It’s our fault we missed the ball on this.  But I am bummed the discussion to change HTML took place in web-perf, as it’s tough to keep the right eyes in all the right places.

~Brady

Received on Thursday, 30 May 2013 16:41:59 UTC