870201 - Navigation Timing connectStart consistently less than domainLookupEnd

Status: RESOLVED DUPLICATE of bug 819685

(Core :: Networking: HTTP, defect)

Description

[jacob]

Attachment: firefox_navtiming.png

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Ubuntu Chromium/25.0.1364.160 Chrome/25.0.1364.160 Safari/537.22

Steps to reproduce:

A. Read the navigation timing spec and gathered that consecutive timestamps should generally be non-decreasing, except where certain timestamps are involved, which must in some cases be zero.  In particular, the spec seems to imply that unless 1) a persistent connection is being used or 2) the current document is retrieved from cache, then connectStart should be greater than or equal to domainLookupEnd.

B. Created a simple test page to display navigation timing values, available here: http://test-pages.s3.amazonaws.com/display-navtiming.html.

C. Visit the test page in Firefox.


Actual results:

A. See that connectionStart is consistently less than domainLookupEnd.

B. Weirdly, the difference between domainLookupStart and fetchStart and the difference between connectStart and domainLookupEnd always seem to be mirror images of one another.  i.e. if domainLookupStart - fetchStart == 123, then connectionStart - domainLookupEnd == -123.


Expected results:

If my understanding of the Navigation Timing spec is correct, connectionStart should never be less than domainLookupEnd.

Comment 1

[jacob]

It appears that connectStart and connectEnd are always equal to fetchStart, even when domainLookupStart and domainLookupEnd are higher.

Comment 2

[Manuela Muntean [Away]]

I can reproduce this issue with the latest Nightly build (build ID: 20130513031057), on Ubuntu 12.10 32bit.

I get the following values:

- connectStart = 1368522487140

- domainLookupEnd = 1368522487142

- domainLookupStart = 1368522487142

- fetchStart = 1368522487140

Comment 3

[Boris Zbarsky [:bzbarsky]]

Manuela, this has nothing to do with xpconnect.  Please stop randomly reassigning bugs....

Jacob, your understanding of the spec as written is right, but the spec is bogus (and I've sent in feedback to that effect before): given speculative TCP preconnects to expired-but-we'll-verify DNS cache entries it is in fact quite possible to have connnectStart happen before domainLookupEnd.  Now the browser can lie about when it started the connection, just to follow the spec, but that seems counterproductive.

That said, I believe in this case all you're seeing is bug 819685 and the document is in fact retrieved from cache.