On May 29, 2013, at 5:34 PM, Boris Zbarsky <[email protected]> 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
