Last Comment Bug 819685 - HTTP channels report timings for DNS even if they read from cache?
: HTTP channels report timings for DNS even if they read from cache?
Status: RESOLVED DUPLICATE of bug 1123920
:
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Valentin Gosu [:valentin] (vacation until 1 Sept)
:
Mentors:
: 870201 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-08 08:43 PST by Boris Zbarsky [:bz]
Modified: 2016-01-07 03:55 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Boris Zbarsky [:bz] 2012-12-08 08:43:02 PST
STEPS TO REPRODUCE:

1)  Load http://w3c-test.org/webperf/tests/submission/W3C/NavigationTiming/monolitic.html
2)  Hit the reload button

ACTUAL RESULTS: The "connectStart-domainLookupEnd" test fails.

EXPECTED RESULTS: No failures with the above steps

ANALYSIS:

As far as I can tell, we never end up with a connectStart in the transaction timings, so the DOM API returns the fetchStart value when asked for connectStart.  But we _do_ end up with DNS timings from our mDNSPrefetch, because we do that no matter whether we're reading from cache.  And of course the domainLookupEnd from the mDNSPrefetch comes after fetchStart.

Can we either kill off the DNS prefetch or at least ignore its timings in cases when we end up not using its results?
Comment 1 Honza Bambas (:mayhemer) 2012-12-12 12:59:13 PST
If the DNS prefetch in this scenario is a potential pref issue, then I'm definitely for to remove it.  I don't have data right now to decide.

I can look how complicated would be to ignore domainLookupEnd when loading from cache.

We also preconnect before a cache entry opens and before we can decide whether to do a net request at all, if I recall correctly.  Then there could be a dns lookup anyway.  Hence some code to ignore/nullify the domainLookupEnd might be appropriate.
Comment 2 Boris Zbarsky [:bz] 2013-02-19 11:35:34 PST
This testcase is now part of the official test suite for the spec at http://w3c-test.org/webperf/tests/approved/navigation-timing/html5/test_timing_attributes_order.html
Comment 3 Boris Zbarsky [:bz] 2013-05-14 08:50:21 PDT
*** Bug 870201 has been marked as a duplicate of this bug. ***
Comment 4 Honza Bambas (:mayhemer) 2016-01-06 11:01:52 PST
Valentin, do you think you could find time to look at this?
Comment 5 Valentin Gosu [:valentin] (vacation until 1 Sept) 2016-01-07 03:55:49 PST
This is no longer reproducible. The bug is more or less the same as bug 1123920.
The solution was to enforce the correct order of the timing objects by returning the previous timing order-wise when one of them was missing. So when connectStart is null because we loaded from the cache, we return domainLookupEnd instead of fetchStart.

*** This bug has been marked as a duplicate of bug 1123920 ***

Note You need to log in before you can comment on or make changes to this bug.