Re: [Web Timing] Getting root timings to recommendation

   Thanks for the thoughts, guys. Pls find comments inline.

On Fri, Aug 20, 2010 at 1:14 PM, Tony Gentilcore <tonyg@google.com> wrote:

>
>
> On Fri, Aug 20, 2010 at 12:40 PM, Zhiheng Wang <zhihengw@google.com>wrote:
>
>>     While working on the draft, I decide to do it slightly different as we
>> discussed yesterday regarding navigationStart.
>>    1) I will keep navigationStart as it is right now, i.e., before Step 1
>> in the current navigation model<http://dev.w3.org/html5/spec/history.html#navigating-across-documents> and
>> where the navigation truely starts.
>>
>
> The navigation doesn't truly start until the user has committed the
> navigation. Consider this scenario:
>
> I. After filling out a POST form, click the back button.
> II. The browser pops up a "Do you wish to repost form data".
> III. Click "OK"
>
> Starting navigationStart before Step 1 means that the clock started ticking
> at step I above. The navigation did not actually start at this point. The
> navigation started when the user committed the navigation by pressing "OK"
> in step III above. Step III above corresponds to after Step 11 in
> http://dev.w3.org/html5/spec/history.html#navigating-across-documents (not
> before step 1).
>
> The same issue exists for "Are you sure you want to leave this page"
> prompts triggered by the beforeunload handler. The clock should not begin
> ticking until after the user said, yes I want to leave this page.
>
> This is crucial to get correct. I can explain more if it still doesn't make
> sense.
>

    This begs the question of how "navigation" is defined, which leads to
the current specification<http://dev.w3.org/html5/spec/history.html#navigating-across-documents>.
But idea behind all these is to
have a timestamp when the user agent starts its very first action/operation
towards the next page. And that's what navigateStart is for.
I understand the user prompt issue. If it's important to have a time
recorded when the user say "Yes" (and I think it is at least for the
POST case here), we can always have more variables added. And I am proposing
to use unloadEventStart.

    And as you might already notice, in case a navigation is cancelled, the
existing window.performance object must not be changed so
it doesn't matter when the cancelled navigation started.


>
>    2) make it explicit that unloadEventStart should be after beforeUnload
>> event is fired. Right now this is where the navigationStart is timed
>>        in IE9 PP4.
>>        Anderson proposed 2) before and as we discussed yesterday, this
>> should practically eliminate most, if not all, security
>>        concerns about unloadEventStart.
>>
>
> unloadEventStart and unloadEventEnd should be defined as immediately before
> and after 5.5.10."unload a document".2 here:
> http://dev.w3.org/html5/spec/history.html#unloading-documents.
>
>      I think we are on the same page here then.

     Another related observation. iirc, both Firefox and IE start the
unloading process after the fetching starts.
How about the "prompt for unloading" part? It's guarantee to be before the
fetch? I always suspect some browsers
are already fetch resource (with GET) behind the scene even before I make my
choice. Some clarification would
definitely help?

cheers,
Zhiheng





>
>>    Please let me know what you think.
>>
>> cheers,
>> Zhiheng
>>
>> On Thu, Aug 19, 2010 at 2:00 PM, Nic Jansma <njansma@microsoft.com>wrote:
>>
>>> One observation on having explicit domLoading and domComplete marks:  Here’s
>>> a snippet of an observed page load in IE9 PP4, showing that domComplete !=
>>> loadEventStart and responseEnd != domLoading, though they are very close
>>> (1-3ms off).
>>>
>>>
>>>
>>> [image: Description: cid:image001.png@01CB3EC2.EE23EB20]
>>>
>>>
>>>
>>> - Nic
>>>
>>>
>>>
>>> *From:* public-web-perf-request@w3.org [mailto:
>>> public-web-perf-request@w3.org] *On Behalf Of *Anderson Quach
>>> *Sent:* Wednesday, August 18, 2010 5:04 PM
>>> *To:* Zhiheng Wang; Tony Gentilcore
>>>
>>> *Cc:* public-web-perf@w3.org
>>> *Subject:* RE: [Web Timing] Getting root timings to recommendation
>>>
>>>
>>>
>>>
>>>
>>> Hi Tony and Zhiheng,
>>>
>>>
>>>
>>> This is a great discussion here. Here are thoughts from Nic and I.
>>>
>>>
>>>
>>> It’s really important that we keep the normative requirements in both
>>> definition and the processing model free from any inconsistencies and
>>> ambiguity. I’m presuming you folks are talking about the differences in
>>> section 4.2 The NavigationTiming Interface and section 4.5 Processing Model
>>> of the Aug 17 working draft [1].
>>>
>>>
>>>
>>> There’s a slight typo in section 4.3 NavigationInfo, the “attribute read
>>> only attribute unsigned short type” is capitalized.
>>>
>>>
>>>
>>> In section 4.4 window.performance.timing, the sample code use a
>>> NavigationInfo.type that does not exist and a  close parenthesis is missing
>>> from the if statement block.
>>>
>>>
>>>
>>> In terms of navigationStart, it is the intention to begin immediately
>>> after the onbeforeunload.
>>>
>>>
>>>
>>> As for the markers related to the document load and unload. It’s our
>>> recommendation to be more explicit about the naming. Currently this is not
>>> updated in the fourth IE platform preview, but it is our intention to update
>>> this as soon as possible.
>>>
>>>
>>>
>>> With the DOM events implemented in the platform preview, the time at
>>> which the DOM readystate transitions to loading can be unique from
>>> responseEnd, and with the readystate transitions to complete can be unique
>>> from loadEventStart.  For consistency and completeness, we would recommend
>>> the standardization of the following markers as it relates to HTML5:
>>> domLoading, domInteractive, domContentLoaded and domComplete.
>>>
>>>
>>>
>>> We share the same concerns with respect to the ability to standardize the
>>> results for firstPaint. All user agents will do different amount of work in
>>> their first paint. I’d recommend either making it a non-normative
>>> requirement, or perhaps not introducing it in the NavigationTiming
>>> interface.
>>>
>>>
>>>
>>> The intention for fullyLoaded is for the site developer to capture when
>>> they declare the page and their content is finished loaded. This can be
>>> marked by the site developer and can be long after loadEventEnd has
>>> completed.  This marker however, is best discussed  in the context of User
>>> Timings.
>>>
>>>
>>>
>>> Timing measures allow for site developers to easily and compactly grab
>>> the time phases within the timeline. The idea here is to enable access to
>>> the overall time it took to navigate, time phases associated with fetching
>>> the document and the time phases associated with loading the document in the
>>> browser.
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> Anderson Quach
>>>
>>> IE Program Manager
>>>
>>>
>>>
>>> [1] http://dev.w3.org/2006/webapi/WebTiming/
>>>
>>>
>>>
>>> *From:* public-web-perf-request@w3.org [mailto:
>>> public-web-perf-request@w3.org] *On Behalf Of *Zhiheng Wang
>>> *Sent:* Tuesday, August 17, 2010 2:19 PM
>>> *To:* Tony Gentilcore
>>> *Cc:* public-web-perf@w3.org
>>> *Subject:* Re: [Web Timing] Getting root timings to recommendation
>>>
>>>
>>>
>>>      This is extremely helpful. Thanks, Tony. Please find comments
>>> inline.
>>>
>>> On Mon, Aug 16, 2010 at 11:08 AM, Tony Gentilcore <tonyg@google.com>
>>> wrote:
>>>
>>> Chrome 7 and the IE9 beta are drawing near. While aggressive, it might be
>>> possible to push to get the Web Timing spec [1] into a recommended state by
>>> then so that we can drop the vendor prefixes for those releases.
>>>
>>>
>>>
>>>     Agree we should moving towards removing the vendor prefixes. As we
>>> discussed out of this thread, fortunately, advancing the draft to
>>> recommendation doesn't necessarily
>>>
>>> block us from doing it (at least for Chrome). :-)
>>>
>>>
>>>
>>>
>>>
>>> I've surveyed the spec and the two implementations and prepared a summary
>>> [2] of the remaining differences. The left most column lists an event or
>>> step in the whatwg HTML5 spec. The next four columns list how the two spec
>>> sections and two implementations label that step. My editorials are on the
>>> right summarizing the differences.
>>>
>>>
>>>
>>> Some high level thoughts:
>>>
>>> 1. The spec has normative requirements in both 4.2 and 4.4. This
>>> introduces the possibility that the spec is internally inconsistent (or at
>>> best redundant). My preference would be for 4.4 to be normative and 4.2 to
>>> be rephrased as non-normative notes.
>>>
>>>
>>>
>>>     I would keep both normative when eliminating any inconsistency and
>>> redundancy (if any). And if one of them has to be relaxed, it should
>>>
>>> be 4.5 (processing model) IMO. Definition is what keep the attributes
>>> consistent across user agents.
>>>
>>>
>>>
>>> 2. The spec could use a careful editorial pass to clean up typos, apply
>>> some formatting to 4.4, and link up more definitions.
>>>
>>>
>>>
>>>     Agree. I will take care of them.
>>>
>>>
>>>
>>> 3. Resource timing needs to be split into another document.
>>>
>>>
>>>
>>>     Done in the latest updates. ResourceTiming is now under
>>> http://dev.w3.org/2006/webapi/ResourceTiming/
>>>
>>> I will send out more notes when I add a couple more points into it.
>>>
>>>
>>>
>>> 4. In terms of the actual implementations, there are only very minor
>>> differences. I think this is all:
>>>
>>>   1. We are pretty close on navigationStart, but we need to be specific
>>> about beforeunload.
>>>
>>>
>>>
>>>     While having it up in the draft for easy discussion, I incline to
>>> remove unloadStart. Security triumphs. That said, I would really like
>>>
>>> to see more feedback from others about this particular issue.
>>>
>>>
>>>
>>>
>>>
>>>   2. [un]loadEvent[Start,End] vs. [un]load[Start,End].
>>>
>>>   3. requestEnd is marked differently.
>>>
>>>   4. dom*, firstPaint, fullyLoaded timings should either be put in the
>>> spec or prefixed w/ ms.
>>>
>>>
>>>
>>> All of this only pertains to window.performance.timing. We probably need
>>> to talk about navigation, timingMeasures, and the new Mark/Measure APIs.
>>>
>>>
>>>
>>>     I believe the new Mark API falls into the UserTiming space? (
>>> http://www.w3.org/2010/08/webperf.html)
>>>
>>>
>>>
>>> thanks,
>>>
>>> Zhiheng
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -Tony
>>>
>>>
>>>
>>> [1] http://dev.w3.org/2006/webapi/WebTiming/
>>>
>>> [2]
>>> https://spreadsheets.google.com/ccc?key=0AvEMl2LYkOQ5dGRLV3Nxc0lCQk0xNTNYRFBFRHlUWXc
>>>
>>>
>>>
>>>
>>>
>>
>>
>