Bug 58699

Summary:

Chromium DevTools: Network panel timing test is flaky

Product:

WebKit

Reporter:

Vsevolod Vlasov <vsevik>

Component:

Web Inspector (Deprecated)

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

abarth, commit-queue, eric, ojan, pfeldman, webkit.review.bot

Priority:

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Attachments:

Description	Flags
Patch	none
Fixed formatting	none

Vsevolod Vlasov

Reported 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?

Attachments
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
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Vsevolod Vlasov

Comment 1 2011-04-18 05:55:53 PDT

Created attachment 90023 [details] Patch

Vsevolod Vlasov

Comment 2 2011-04-18 05:58:51 PDT

Created attachment 90024 [details] Fixed formatting

Eric Seidel (no email)

Comment 3 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?

Vsevolod Vlasov

Comment 4 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.

WebKit Commit Bot

Comment 5 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>

WebKit Commit Bot

Comment 6 2011-04-19 09:36:28 PDT

All reviewed patches have been landed. Closing bug.

WebKit Review Bot

Comment 7 2011-04-19 10:42:04 PDT

http://trac.webkit.org/changeset/84258 might have broken Windows 7 Release (Tests)

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