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

So then, let's settle on calling the visibility handler after pagehide, and
also before pageshow if the page is coming from the pagecache.  Also, given
that the event is fired after pagehide, we don't need to overload the
visibilityState attribute with states like "suspended" or "unloaded". So
let's remove those two states from the list (
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility/Overview.html#dom-document-visibilitystate
).

Please comment if you have any concerns.

Arvind

On Tue, May 15, 2012 at 10:58 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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
>
>