Re: [whatwg] pagehide vs pagevis

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

> 

>> I’ve tried these search terms and the only obviously relevant thing I
>> could find was
>> http://lists.w3.org/Archives/Public/public-web-perf/2012Feb/0111.html
> 
> Uh... http://www.w3.org/Search/Mail/Public/search?keywords=pagehide&hdr-1-name=subject&hdr-1-query=visibility&index-grp=Public_FULL&index-type=t&type-index=public-web-perf
> 
> http://lists.w3.org/Archives/Public/public-web-perf/2012May/0101.html is one relevant mail, but you may want to read the whole thread.
> 
> I'm not sure why I have to be doing basic mailing list searches for you....

Thank you for the link to the specific thread you were thinking of.

As I mentioned, I performed the search you suggested but - since there were a large number of results and I didn’t have any additional insight on what I was looking for - I didn’t find this message.

So it appears the rationale was mostly in http://lists.w3.org/Archives/Public/public-web-perf/2012May/0079.html:
> >>> The reason I want to fire visibilitychange before pageshow and after
> >>> pagehide is that:
> >>> 1)  The latter preserves the invariant that it actually triggers on
> >>> visibility state changes: it fires after we're actually hidden.
> >>> 2)  The former preserves the general ordering of visibility changes and
> >>> page show/hide.  During a document load, for example, the document becomes
> >>> visible (there is no event for this initial visibility change) and then
> >>> fires pageshow sometime later, right?
> >>
> >>
> >> I see your point. I think we should define visibilitychange as occurring
> >> before pageshow and after pagehide. Additionally, we will need to specify
> >> that visibilitychange needs to occur after the beforeunload event.
> 
Part 1 of the rationale seems inapplicable to me.

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.

I’m aware that “page showing” is a flag for internal processing and not actually reflective of whether or not the Document is “visible” but it’s the best indication I can find.  Also, before the "unloading document visibility change steps” existed, pagehide and unload events were dispatched back-to-back with no “make the document actually be invisible” step between them.

If there is language in HTML that describes how the document is still visible when pagehide is fired and invisible when unload is fired and therefore the visibility event has to come in between them, I could not find it.  I would appreciate a pointer.

Part 2 of the rationale is only about pageshow, and also seems to me to include a non-fact:
"During a document load, for example, the document becomes visible (there is no event for this initial visibility change) and then fires pageshow sometime later, right?”

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.

I also don’t see a hook for visibilitychanged in the historytraversal algorithm where pageshow with persisted set to true is fired.  Therefore i have no specifics on the spec’d behavior to reference.

I can think of one scenario already where a visibilitychanged event would *not* come before pageshow, and that’s when a page is being restored from a page cache in a background tab, and therefore its visibility is not actually transitioning.

There doesn’t seem to be a reason why the visibility event has to come before pageshow *besides* symmetry with the prior visibility event coming after pagehide.
> Chrome is fine with this change (firing the visibility change event
> after pagehide and before pageshow).
> 
> It may have been nice to keep the invariant that pagehide is the last
> event before a page is frozen, the same way that unload is the last
> event on a page, but I can be convinced that the advantages of the
> proposal outweigh that consistency hobgoblin (apart from what Boris
> said above, firing it after pagehide means we don't _need_ more
> detailed visibility states such as "suspended").


While I wish Sreeram had brought this up with the WebKit community when making this statement, as a vendor representative for Chrome he’s entitled to a differing opinion.  He probably also didn’t see why this is a big concern to us because at that time Chrome was not using the WebKit page cache.

That said, he does point out one of the reasons we’re arguing for flipping the event order here.

As for "firing it after pagehide means we don't _need_ more detailed visibility states such as “suspended””, I have a few comments.

First, since pagehide currently always has persisted set to true (in the spec and in Gecko), it doesn’t actually describe whether or not the page is going in to the page cache.
Second, imagining a world where pagehide allows persisted to differ between true or false, to know that a “hidden” corresponds with a “page going in to the page cache”, you still have to listen to both events to know the whole situation.
Third, is the difference between 4 states and 5 states really appreciable?

~Brady

Received on Wednesday, 29 May 2013 20:31:08 UTC