RE: [Web Timing] Getting root timings to recommendation

Tony's got it, the navigationStart in scenarios where there is a prompt to unload the document object, http://dev.w3.org/html5/spec/history.html#prompt-to-unload-a-document. The navigationStart should begin immediately after step 11.

Counting navigationStart before Step 1 would include the time where there can be an arbitrary amount of time where an end-user ask to make a continue or abort decision to proceed with the navigation.

It's recommended that in the processing model, navigationStart begins from when the user has committed a navigation decision.

Anderson Quach
IE Program Manager

From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Tony Gentilcore
Sent: Friday, August 20, 2010 1:15 PM
To: Zhiheng Wang
Cc: Nic Jansma; Anderson Quach; public-web-perf@w3.org
Subject: Re: [Web Timing] Getting root timings to recommendation


On Fri, Aug 20, 2010 at 12:40 PM, Zhiheng Wang <zhihengw@google.com<mailto: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.

   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.


   Please let me know what you think.

cheers,
Zhiheng

On Thu, Aug 19, 2010 at 2:00 PM, Nic Jansma <njansma@microsoft.com<mailto: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).

[Description: cid:image001.png@01CB3EC2.EE23EB20]

- Nic

From: public-web-perf-request@w3.org<mailto:public-web-perf-request@w3.org> [mailto: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<mailto: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> [mailto: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<mailto: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<mailto: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