- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 15 May 2012 13:58:03 -0400
- To: Sreeram Ramachandran <sreeram@google.com>
- CC: public-web-perf@w3.org
On 5/15/12 1:21 PM, Sreeram Ramachandran wrote: > On Tue, May 15, 2012 at 8:56 AM, Boris Zbarsky<bzbarsky@mit.edu> wrote: >> On 5/15/12 11:30 AM, Sreeram Ramachandran wrote: >>> >>> Do we need to clarify in the spec that the event fires between load >>> and pageshow >> >> There would be no visibility change event during an initial page load, if it >> happened in a foreground tab, since the page starts out visible and there is >> no visibility change. > > So, to be consistent, I think we should say that visibility change is > NOT fired after pagehide in the case of a true unload This would not be consistent, actually. The reason is that load and unload are fundamentally asymmetric: while you can't get a reference to a document before the loading process starts, you _can_ keep a reference to the document after unload. So there is no way to observe the transition from "no document" to "visible document" when the load starts if the document is loading in a foreground tab. But there is very much a way to observe the transition from "visible document" to "invisible document" when the tab is unloading. > thus distinguishing it from the case of a document going into the page > cache. Why would that be a useful distinction for purposes of this API? > I.e., in a normal load/unload scenario, the document never sees a > visibilitychange event. This leads to documents that script has access to that go from being visible to not being visible without firing such an event... -Boris
Received on Tuesday, 15 May 2012 18:18:58 UTC