Closed Bug 1263428 Opened 10 years ago Closed 10 years ago

Intermittent test_resource_timing.html | PerformanceEntry has correct order of timing attributes (link) - assert_greater_than_equal: connectStart after domainLookupEnd expected a number greater than or equal to 482.3286635493814 but got 482.28181595114637

Categories

(Core :: Networking, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox47 --- unaffected
firefox48 --- fixed
firefox49 --- fixed

People

(Reporter: aryx, Assigned: valentin)

Details

(Keywords: intermittent-failure, regression, Whiteboard: [necko-active])

Attachments

(1 file)

https://treeherder.mozilla.org/logviewer.html#?job_id=25480412&repo=mozilla-inbound 23:53:17 INFO - TEST-PASS | /resource-timing/test_resource_timing.html | PerformanceEntry has correct name, initiatorType, startTime, and duration (img) 23:53:17 INFO - TEST-PASS | /resource-timing/test_resource_timing.html | PerformanceEntry has correct order of timing attributes (img) 23:53:17 INFO - TEST-PASS | /resource-timing/test_resource_timing.html | window.performance.getEntriesByName() and window.performance.getEntriesByNameType() return same data (link) 23:53:17 INFO - TEST-PASS | /resource-timing/test_resource_timing.html | PerformanceEntry has correct name, initiatorType, startTime, and duration (link) 23:53:17 INFO - TEST-UNEXPECTED-FAIL | /resource-timing/test_resource_timing.html | PerformanceEntry has correct order of timing attributes (link) - assert_greater_than_equal: connectStart after domainLookupEnd expected a number greater than or equal to 482.3286635493814 but got 482.28181595114637 23:53:17 INFO - test@http://web-platform.test:8000/resource-timing/test_resource_timing.js:171:9 23:53:17 INFO - Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1382:20 23:53:17 INFO - resource_load@http://web-platform.test:8000/resource-timing/test_resource_timing.js:162:5 23:53:17 INFO - inner/<@http://web-platform.test:8000/resource-timing/test_resource_timing.js:124:25 23:53:17 INFO - setTimeout handler*inner@http://web-platform.test:8000/resource-timing/test_resource_timing.js:123:21 23:53:17 INFO - setTimeout handler*inner@http://web-platform.test:8000/resource-timing/test_resource_timing.js:130:9 23:53:17 INFO - poll_for_stylesheet_load@http://web-platform.test:8000/resource-timing/test_resource_timing.js:132:5 23:53:17 INFO - onload@http://web-platform.test:8000/resource-timing/test_resource_timing.js:88:13 23:53:17 INFO - EventHandlerNonNull*@http://web-platform.test:8000/resource-timing/test_resource_timing.js:26:1 23:53:17 INFO - TEST-PASS | /resource-timing/test_resource_timing.html | window.performance.getEntriesByName() and window.performance.getEntriesByNameType() return same data (script)
This is a regression - e10s only - caused by a push that occurred on April 1st or before. Some of the orange failures were recorded in bug 1141370. I've looked at the change log and I don't think the networking changes can account for this regressions. There were a couple of e10s patches, but I don't see how it would lead to this failure.
Assignee: nobody → valentin.gosu
Keywords: regression
Whiteboard: [necko-active]
Flags: needinfo?(valentin.gosu)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
This is not yet fixed. Still debugging. Setting leave-open flag.
Status: RESOLVED → REOPENED
Flags: needinfo?(valentin.gosu)
Keywords: leave-open
Resolution: FIXED → ---
I actually think this should fix the issue. This was a racy condition, where we assumed that if requestStart is null, then this is not a persistant connection. The assumption was false, and when OnLookupComplete fired before had started sending the request, it would set a domainLookupEnd that was larger than connectStart.
Attachment #8746115 - Flags: review?(mcmanus)
Comment on attachment 8746115 [details] [diff] [review] Make sure we don't set the domainLookupEnd timestamp after connectStart for non-persistant connections Review of attachment 8746115 [details] [diff] [review]: ----------------------------------------------------------------- ::: netwerk/protocol/http/nsHttpChannel.cpp @@ +6093,5 @@ > mTransactionPump = nullptr; > > // We no longer need the dns prefetch object > if (mDNSPrefetch && mDNSPrefetch->TimingsValid() > && !mTransactionTimings.requestStart.IsNull() do you still need the requestStart null check?
Attachment #8746115 - Flags: review?(mcmanus) → review+
(In reply to Patrick McManus [:mcmanus] from comment #21) > > && !mTransactionTimings.requestStart.IsNull() > > do you still need the requestStart null check? I left it in so we wouldn't change the behaviour - in case the connect fails.
https://hg.mozilla.org/integration/mozilla-inbound/rev/119f55446e975341b3d09cd4036dc39a3b59ec82 Bug 1263428 - Make sure we don't set the domainLookupEnd timestamp after connectStart for non-persistant connections r=mcmanus
No failures since it landed on central. I think we can mark this as fixed.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Thanks!
Keywords: leave-open
Target Milestone: mozilla48 → mozilla49
Can you please request Aurora approval on this when you get a chance?
Flags: needinfo?(valentin.gosu)
Comment on attachment 8746115 [details] [diff] [review] Make sure we don't set the domainLookupEnd timestamp after connectStart for non-persistant connections Approval Request Comment [Feature/regressing bug #]: Bug 1123920 [User impact if declined]: intermittent failures when DNS prefetch is involved. [Describe test coverage new/current, TreeHerder]: both mochitests and WPT [Risks and why]: low risk. Patch makes sure we only use DNS prefetch timings when they make sense. [String/UUID change made/needed]: none.
Flags: needinfo?(valentin.gosu)
Attachment #8746115 - Flags: approval-mozilla-aurora?
Comment on attachment 8746115 [details] [diff] [review] Make sure we don't set the domainLookupEnd timestamp after connectStart for non-persistant connections Fix an intermittent, taking it.
Attachment #8746115 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: