- 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>
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. Thanks, Jatinder
Received on Wednesday, 5 December 2012 19:40:29 UTC