Re: Updates to Navigation Timing errata

How should such cases be handled?

The DNS resolution, TCP connect, root page download (via prefetch hint) and
entire page download (via prerender hint) can all start before actual user
navigation and finish before or after navigationStart. In such cases, what
should be the values for the different timing attributes in these cases?

Taking the example of DNS resolution, with a pre-resolve, the spec seems to
state that domainLookupStart would be the time when the pre-resolve is
actually started. But I think it makes more sense to talk in context of
user navigation - a pre-resolve should be treated like a cache hit, so if a
pre-resolve finished before navigationStart, we should report
domainLookupStart and End == fetchStart.

What is your preference?

Arvind


On Tue, May 14, 2013 at 9:51 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 5/14/13 10:49 AM, Philippe Le Hegaret wrote:
>
>> It includes two errata, one regarding the navgiationStart attribute, and
>> one regarding the illustration in 5.1 Processing Model.
>>
>
> I hate sounding like a broken record, but this is still assuming a model
> in which "TCP" comes after "DNS" and "DNS" comes after "Prompt for Unload".
>
> In actual browsers, "DNS" can happen when the user hovers over the link
> that they will click to leave the page (before "Prompt for unload") and
> "TCP" can start before "DNS" completes due to speculative preconnects....
>
> As a result, a browser implementing this specification right now has the
> choice of either not following the spec or reporting numbers that don't
> reflect what it actually did.  In practice I believe at least Gecko ends up
> doing a mix of the two depending on where people remembered to put in
> random max() or min() calls; I can't speak to other browsers.
>
> -Boris
>
>