Re: [Web Timing] WebKit's planned processing model

Hi, Anderson,

   Pls find comments inline.

On Fri, Jul 30, 2010 at 3:44 PM, Anderson Quach <aquach@microsoft.com>wrote:

> Having the times at which the document.readyState is rather useful in terms
> of tuning and optimizing site performance. It helps to surface the time
> delay between scripts marked deferred / interactive state and when the
> document is consider complete.
>
>
>
> With respect to document.readyState, to gain access to the times of each
> onreadystatechange transition, a developer would have to register the
> callback to record the timestamp per transition. Making the timestamps
> readily available in the performance.timing object would free her from
> having to register these callbacks.
>
>
>
> Also, having this type of timing information easily accessible in the
> Navigation Timing interface, there’s consistency and reduced overhead to get
> access to the readystate change times. All in all there the  benefits are:
>
> i.                     completeness in the navigation timeline
>
> ii.                   simplicity with accessing the timing information
>
> iii.                  prevention of instrumentation based overhead for
> having the developer to register for these events herself.
>
    I agree with most of the points here. :-) and, DomInteractive seems to
be an interesting data point. My questions are more towards other
data points in the IE's document.readyState:
   * unintialized/loading - not much value to WebTiming IMHO.
   * loaded/complete - I am not sure exactly what is the difference in
between. WebTiming already has onloadStart/onloadEnd
     so how much added value they have?


>
>
> In terms of mitigating the information disclosure attack surface, perhaps
> the best way to prevent this type of attack is not to provide the
> information in cross-domain scenarios. Where transitioning from abc.com à
> xyz.com the unloadEventStart and unloadEventEnd is zeroed.
>

      SOP usually is too strict but it could be a potential solution.


> Again the most valuable timestamp is the unloadEventEnd, an attacker can
> infer the start as the navigationStart.
>

     iirc, unload starts after some sort of response is received by the user
agent?

cheers,
Zhiheng



>
>
> Best Regards,
>
> Anderson Quach
>
> IE Program Manager
>
>
>
>
>
> *From:* tonyg@google.com [mailto:tonyg@google.com] *On Behalf Of *Tony
> Gentilcore
> *Sent:* Thursday, July 29, 2010 9:59 AM
> *To:* Zhiheng Wang
> *Cc:* Anderson Quach; public-web-perf@w3.org
>
> *Subject:* Re: [Web Timing] WebKit's planned processing model
>
>
>
>
>
> On Thu, Jul 29, 2010 at 1:10 AM, Zhiheng Wang <zhihengw@google.com> wrote:
>
>
>
> On Sun, Jul 25, 2010 at 11:04 AM, Zhiheng Wang <zhihengw@google.com>
> wrote:
>
> Hi, Anderson,
>
>    Please see comments inline.
>
> On Fri, Jul 23, 2010 at 3:22 PM, Anderson Quach <aquach@microsoft.com>
> wrote:
>
> Zhiheng and Tony, thanks for getting together to update the Web Timing
> working draft. Here’s some feedback Nic & I have with the July 21st 2010
> version [1].
>
>
>
> It would be pretty interesting to include markers that relate to
> document.readyState [2]. This will help site developers further understand
> what’s happening during the navigation as the page is loading, including
> states like loading, interactive, and complete.
>
>     Since developers already have convenient access to document.readyState
> right now, including
>
> it in WebTiming seems to be something redundant.
>
>
>
>    To clarify, I agree that having these times available in
> window.performance.timing provides easier access. Exposing
>
> redundant data just makes me wonder.
>
>
>
>    After some homework, I might have to take it back though. The current
> spec <http://www.w3.org/TR/html5/dom.html#resource-metadata-management> requires document.readyState
> to
>
> offer "loading" and "complete" only, which seem to be what Chrome and FF
> are following.
>
>
>
> In WebKit, the "interactive" ready state just isn't implemented yet (but it
> will be). Here's the definition of "interactive":
>
> http://dev.w3.org/html5/spec/Overview.html#the-end
>
>
>
>  IE have additional state values<http://msdn.microsoft.com/en-us/library/ms534359(VS.85).aspx>
> .
>
> So here are some thoughts to share:
>
>    * unintialized/loading - not much value to WebTiming IMHO.
>
>    * interactive - this should be an interesting POI during a page load
>
>    * loaded/complete - I am not sure exactly what is the difference in
> between. WebTiming already has onloadStart/onloadEnd
>
>      so how much added value they have?
>
>
>
> cheers,
>
> Zhiheng
>
>
>
>
>
>
>
>
>
> The suggested markers are:
>
> ·         domLoading
>
> ·         domInteractive
>
> ·         domContentLoaded
>
> ·         domComplete
>
>
>
> In section 4.2 of the Web Timing draft [1]:
>
>
>
> unloadEventEnd is defined as the timestamps which relates to the unloading
> of the last document. As the marker is named, you may have meant to be
> defined as the time immediately when the unload event of the previous
> document is complete.
>
>    unloadEventEnd is meant for the time when the unloading document cleanup
> steps [1] are completed for
>
> the browsing context of the previous navigation and its descendants
> browsing context. The unload event of the root
>
> browsing context is fired before these steps.
>
>
>
>   [1]
> http://www.w3.org/TR/html5/history.html#unloading-document-cleanup-steps
>
>
>
>
>
> A suggestion, how about  complementing unloadEventEnd with
> unloadEventStart.
>
>   This is something we should have further discussion over. As we discuss,
> exposing both
>
> Start and End of the unload process reveals some information on the
> previous page's unload
>
> event handling. Combining with the referrer, it causes some privacy
> concern.
>
>
>
>   This is a topic of the ongoing security review of the draft here. What
> are the thoughts from others?
>
>
>
> redirectEnd for clarity, the recommendation here is to be more explicit
> about the time maker for the last redirected navigation. E.g. If the last
> navigation is a redirection, this attribute must return the number of
> milliseconds between midnight of January 1, 1970 (UTC) and the time when the
> last redirected navigation ends.
>
>    Here is the current definition:
>
>   "If the last navigation is a redirection, this attribute must return the
> number of milliseconds between midnight of January 1, 1970 (UTC) and the
>
> time when the last navigation ends. If the last navigation is not a
> redirect, this attribute must return zero."
>
>    It looks the same to me?
>
>
>
>
>
>
>
> Within the NavigationInfo interface, to be consistent, the suggestion here
> is to use the lower case type, rather than the capitalized Type. This may
> have been a typo.
>
>    Right, I've changed it to navigation.type.
>
>
>
>
>
> The code sample for NavigationInfo has a few code snippet errors.
>
>
>
> var t = performance.timing;
>
> if (t.timing.navigationEnd > 0) {
>
>   var page_load_time = t.timing.navigationEnd - t.timing.navigationStart;
>
>   if (t.navigation.Type == t.navigation.TYPE_LINK) {
>
>   alert (page_load_time);
>
> }
>
>
>
> Should be:
>
> var t = performance.timing;
>
> if (t.timing.navigationEnd > 0) {
>
>   var page_load_time = t.timing.navigationEnd - t.timing.navigationStart;
>
>   if (performance.navigation.type == performance.navigation.TYPE_NAVIGATE) {
>
>   alert (page_load_time);
>
> }
>
>
>
>
>
>    Thanks for catching this. Fixed.
>
>
>
>
>
> In the code example, you make mention of navigationEnd which is not defined
> in the document. The feedback here is that, it’s a great complement to
> navigationStart to denote the logical start and end of the navigation phase.
> Just thinking about how a site developer would intuitively think about the
> timeline, having a navigationStart paired with a navigationEnd along with a
> fetchStart and fetchEnd would help bring clarity to the phases of loading
> the root document.  Where, navigationEnd corresponds with loadEventEnd and
> fetchEnd with responseEnd. Thoughts?
>
>     In longer term, having two distinct variables referring to the same
> value soundslike a good way
>
> to get developers confused. :-) Just my $0.02.
>
>
>
> thanks,
>
> Zhiheng
>
>
>
>
>
>
>
>
>
> [1] Web Timing http://dev.w3.org/2006/webapi/WebTiming/
>
> [2] Resource metadata management
> http://www.w3.org/TR/html5/dom.html#resource-metadata-management
>
>
>
> 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:* Thursday, July 15, 2010 5:38 PM
> *To:* public-web-perf@w3.org
> *Subject:* Re: [Web Timing] WebKit's planned processing model
>
>
>
> I made two updates to my description of WebKit's processing model:
>
> 1. domainLookupStart, domainLookupEnd, connectStart, and connectEnd are now
> "backfilled" when they would have previously returned 0.
>
> 2. Nic Jansma uncovered a bug. In 3.10.b, redirect-start should be set only
> if it is currently 0.
>
>
>
> Here is the live link. Revision history is at the bottom.
>
>
> https://docs.google.com/document/edit?id=1rZQ_XaiEwb4OL62DGHXY1Ktzk7PhgkHTYlzpnZEeYKw
>
> On Tue, Jul 13, 2010 at 1:52 PM, Tony Gentilcore <tonyg@chromium.org>
> wrote:
>
> Attached[1] is my plan for the processing model of WebKit's initial
> window.webkitPerformance implementation.
>
>
>
> I'm hoping its detailed language will be useful in informing the working
> draft specification <http://dev.w3.org/2006/webapi/WebTiming/>. I'm also
> very interested to make sure this lines up with the IE9 and Mozilla
> implementation plans. All feedback appreciated.
>
>
>
> Tony
>
>
>
> [1] HTML exported from Google Docs. Let me know if you'd like me to share
> the original.
>
>
>
>
>
>
>
>
>