Bug 58699 - Chromium DevTools: Network panel timing test is flaky
Summary: Chromium DevTools: Network panel timing test is flaky
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2011-04-15 15:09 PDT by Vsevolod Vlasov
Modified: 2011-04-19 10:42 PDT (History)
6 users (show)

See Also:

Patch (2.10 KB, patch)
2011-04-18 05:55 PDT, Vsevolod Vlasov
no flags Details | Formatted Diff | Diff
Fixed formatting (2.13 KB, patch)
2011-04-18 05:58 PDT, Vsevolod Vlasov
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vsevolod Vlasov 2011-04-15 15:09:09 PDT
Apparently following condition leads to flakiness:
resource.endTime - resource.responseReceivedTime >= 0.1

I assume responseReceivedTime could come a bit later than expected causing failure.
resource.endTime - resource.startTime >= 0.2 condition seems to be more reliable.
What do you think?
Comment 1 Vsevolod Vlasov 2011-04-18 05:55:53 PDT
Created attachment 90023 [details]
Comment 2 Vsevolod Vlasov 2011-04-18 05:58:51 PDT
Created attachment 90024 [details]
Fixed formatting
Comment 3 Eric Seidel (no email) 2011-04-18 09:35:02 PDT
Comment on attachment 90024 [details]
Fixed formatting

This could only reduce flakiness, not eliminiate it.  Is there a way to do this test not involving timings?
Comment 4 Vsevolod Vlasov 2011-04-18 09:50:27 PDT
First of all the whole point of this test is to check that timings information coming from network stack (through the net log) is correct, so it would be hard to test that without timings.
Essentially, this is our way to test that devtools_netlog_observer working on the real network stack gives us correct data.

Secondly, I believe this should eliminate flakiness. I guess the only reason test was failing before was flush() behavior on testserver. The beginning and the end of the response could have come in the same piece of data, thus making resource.endTime - resource.responseReceivedTime close to zero.
Comment 5 WebKit Commit Bot 2011-04-19 09:36:21 PDT
Comment on attachment 90024 [details]
Fixed formatting

Clearing flags on attachment: 90024

Committed r84258: <http://trac.webkit.org/changeset/84258>
Comment 6 WebKit Commit Bot 2011-04-19 09:36:28 PDT
All reviewed patches have been landed.  Closing bug.
Comment 7 WebKit Review Bot 2011-04-19 10:42:04 PDT
http://trac.webkit.org/changeset/84258 might have broken Windows 7 Release (Tests)