Bug 58143

Summary: PerformanceTiming returns inconsistent values when timing is null.
Product: WebKit Reporter: Vsevolod Vlasov <vsevik>
Component: Page LoadingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: caseq, commit-queue, eric, jamesr, pfeldman, simonjam, tonyg
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Attachments:
Description Flags
Patch none

Vsevolod Vlasov
Reported 2011-04-08 08:54:22 PDT
PerformanceTiming returns inconsistent values when timing is null.
Attachments
Patch (3.89 KB, patch)
2011-04-08 14:53 PDT, Vsevolod Vlasov 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Vsevolod Vlasov
Comment 1 2011-04-08 14:53:28 PDT
Created attachment 88876 [details] Patch
Eric Seidel (no email)
Comment 2 2011-04-10 15:42:48 PDT
Comment on attachment 88876 [details] Patch How do we test this?
Vsevolod Vlasov
Comment 3 2011-04-10 17:20:02 PDT
This is tested in fast/dom/webtiming*.html layout tests. After landing of http://codereview.chromium.org/6823006/ these tests would fail, unless this patch is also landed.
Eric Seidel (no email)
Comment 4 2011-04-10 17:35:12 PDT
(In reply to comment #3) > This is tested in fast/dom/webtiming*.html layout tests. > After landing of http://codereview.chromium.org/6823006/ these tests would fail, unless this patch is also landed. Ideally the ChagneLog would contain this information. :)
Pavel Feldman
Comment 5 2011-04-10 23:04:33 PDT
Comment on attachment 88876 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=88876&action=review > Source/WebCore/page/PerformanceTiming.cpp:264 > + return requestStart(); You probably should do the same for the secureConnection timers above and for the responseEnd below.
Vsevolod Vlasov
Comment 6 2011-04-11 10:33:59 PDT
Comment on attachment 88876 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=88876&action=review >> Source/WebCore/page/PerformanceTiming.cpp:264 >> + return requestStart(); > > You probably should do the same for the secureConnection timers above and for the responseEnd below. secureConnection: "If this attribute is available but HTTPS is not used, this attribute must return zero.", so zero is correct. respondEnd is filled from documentLoadTiming, not resourceLoadTiming, so its value is correct as well.
Tony Gentilcore
Comment 7 2011-04-11 10:46:23 PDT
Thanks for taking care of this.
WebKit Commit Bot
Comment 8 2011-04-11 13:43:15 PDT
The commit-queue encountered the following flaky tests while processing attachment 88876 [details]: fast/workers/storage/use-same-database-in-page-and-workers.html bug 50995 (author: dumi@chromium.org) The commit-queue is continuing to process your patch.
WebKit Commit Bot
Comment 9 2011-04-11 13:45:55 PDT
Comment on attachment 88876 [details] Patch Clearing flags on attachment: 88876 Committed r83491: <http://trac.webkit.org/changeset/83491>
WebKit Commit Bot
Comment 10 2011-04-11 13:46:00 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.