- From: Sreeram Ramachandran <sreeram@google.com>
- Date: Tue, 15 May 2012 08:30:10 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Jatinder Mann <jmann@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>, "arvind@google.com" <arvind@google.com>
On Fri, Feb 3, 2012 at 12:12 PM, Boris Zbarsky <bzbarsky@mit.edu> 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 http://dev.w3.org/html5/spec/single-page.html#the-end) 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