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

On 12/5/12 2:39 PM, Jatinder Mann wrote:
>> 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?

I don't think we want the steps running synchronously when switching 
tabs or unminimizing...

One other note.  Now that I read this section again, the tests at 
http://w3c-test.org/webperf/tests/submission/Microsoft/PageVisibility/test_minimize.htm 
and 
http://w3c-test.org/webperf/tests/submission/Microsoft/PageVisibility/test_tab_state_change.htm 
flat-out contradict it.  Is the bug in the spec, or in the tests?  Gecko 
as currently shipped does what the spec right now says here for the 
tab-switch and unminimize cases.

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

Striking step 1 is needed, yes.  Once you do that, you run into the same 
issue as above: when unloading you want to run the three steps, not 
queue a task to run the three steps.

-Boris

Received on Friday, 7 December 2012 03:44:51 UTC