Performance timing redirectEnd includes time for the page loading
Reported by
taavo.t...@plumbr.io,
Mar 19 2018
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36 Steps to reproduce the problem: 1. Have a site where a link redirects after 1s to a page that loads after 500ms 2. Click on link to redirect 3. Check performance.timing What is the expected behavior? performance.timing.redirectEnd - performance.timing.redirectStart should be (around) 1000 What went wrong? redirectEnd timestamp matches responseEnd, making redirectEnd - redirectStart be ~1500 (duration of redirect + page loading) Did this work before? N/A Does this work in other browsers? Yes Chrome version: 65.0.3325.162 Channel: stable OS Version: 10.0 Flash Version: Additionally timings from fetchStart to connectEnd all also match responseEnd timestamp
,
Mar 19 2018
,
Mar 21 2018
Verified that: Chrome: performance.timing.redirectEnd - performance.timing.redirectStart = ~1500 Firefox: performance.timing.redirectEnd - performance.timing.redirectStart = ~1000 Move the bug to available.
,
Mar 26 2018
Vote for this issue and get email change notifications
,
Mar 26 2018
Components: -Blink>PerformanceAPIs Blink>PerformanceAPIs>NavigationTiming
,
Mar 26 2018
Verified that: Chrome: performance.timing.redirectEnd - performance.timing.redirectStart = ~1500 Firefox: performance.timing.redirectEnd - performance.timing.redirectStart = ~1000 Move the bug to available.
,
May 7 2018
P1: Do we have the same issue with nav timing 2? If not, maybe this is P2. We should have a test for this though.
,
May 8 2018
I'm able to reproduce the original test case but unable to reproduce the result in #8. I get pretty small values for the navigation entry. What Chrome version are you using for that?
,
May 9 2018
That was with 66.0.3359.139 (current stable) Tested just now with canary 68.0.3424.0 and both nav timings 1 & 2 methods seem fixed
,
May 17 2018
Ok, thanks! In that case, reducing priority.
,
Sep 4
Ping from bug triage: Any update on this?
,
Sep 6
Sorry, no update yet. CC Tom who might be interested in looking at this.
,
Sep 6
Sounds like a bisect between 68.0.3424.0 (canary) and 66.0.3359.139 (stable) could give us some insight into what happened to fix things per #10.
,
Sep 7
I'm running a bisect now... will update this bug if/when I find a candidate CL.
,
Sep 7
My bisect is implying the fix was introduced in 44cc16cdbb7589055303042d621336578b818d95 (CL: https://chromium-review.googlesource.com/981913). I took a peek at the CL and it seems reasonable that the change fixed this issue. What's the next step? Perhaps a regression test? Or just mark fixed?
,
Sep 7
I think a regression test would be nice and then we can mark this as Fixed. Do you want to take over that or shall I do it?
,
Sep 7
I'll take it on.
,
Sep 11
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1c4c53cc3a3106373080ceedc6d21dc324e6654d commit 1c4c53cc3a3106373080ceedc6d21dc324e6654d Author: Tom McKee <tommckee@chromium.org> Date: Tue Sep 11 12:28:13 2018 Adding a regression test against crbug.com/823254 . BUG= 823254 Change-Id: Ibfa232b39e7003565ac68dba0e4e1aab9170c6fd Reviewed-on: https://chromium-review.googlesource.com/1216845 Commit-Queue: Tom McKee <tommckee@chromium.org> Reviewed-by: Nate Chapin <japhet@chromium.org> Cr-Commit-Position: refs/heads/master@{#590272} [modify] https://crrev.com/1c4c53cc3a3106373080ceedc6d21dc324e6654d/third_party/blink/renderer/core/loader/document_load_timing_test.cc
,
Sep 11
Regression test just landed... marking as fixed. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by tdres...@chromium.org
, Mar 19 2018