Re: [Page Visibility] Navigate away behavior (was RE: TPAC 2011 Web Performance WG 2011-11-01)

On Fri, Feb 3, 2012 at 12:12 PM, Boris Zbarsky <> wrote:
>>> 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.

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

Do we need to clarify in the spec that the event fires between load
and pageshow (i.e., add a similar hook to and that it
only fires if the visibility state has changed from the document's
initial visibility state?

Received on Tuesday, 15 May 2012 15:31:21 UTC