W3C home > Mailing lists > Public > public-web-perf@w3.org > December 2012

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

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 5 Dec 2012 19:39:22 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>, "'public-web-perf@w3.org'" <public-web-perf@w3.org>
Message-ID: <82cb08a5768e4400bfaedb6206bf1987@BY2PR03MB074.namprd03.prod.outlook.com>
On 7/31/2012 1:17 PM, Boris wrote:
> I'm not sure I follow this section, still.  For example. let's take the "now at least partially visible" case when traversing 
> to a session history entry.  The condition in step 1 tests true, so step 2 runs right before the firing of pageshow.  Step 
> 2 queues a task to perform 3 substeps.  Then it returns, the pageshow event fires, and then the queued task is 
> executed, so the visibilitychange fires after pageshow.
> Similar for the "now not visible" steps, except there the visibilitychange will run after unload.
> I assume in both cases what's really desired is to give a name to the three-step algorithm and to run it right before 
> pageshow when traversing to a session history entry or off a task when not for the "now visible" 
> case, and likewise run it right after pagehide or during the unload steps when unloading or off a task when not in 
> the "not visible" case.

Would it suffice to remove the "Queue a task" and simply state "Run the following steps synchronously" for step 2 in the at least partially visible and step 3 in the not visible sections?

On 7/31/2012 1:17 PM, Boris wrote:
> Also, isn't it possible to both be traversing from a history entry _and_ unloading?  I don't see why you need to say 
> anything about traversing from session history entries apart from saying that "unloading document visibility change 
> steps" involves firing visibility change stuff.

I see that the unload processing model (step 2) already covers firing the pagehide event. Would it suffice to just strike step 1 from the now not visible steps?

I believe this feedback received in the CR state is meant to clarify the intention of the spec's processing model. I don't expect this type of feedback would change the spec's CR status.

Received on Wednesday, 5 December 2012 19:40:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:33 UTC