Seems like receive time is not correct according to net-internals
Reported by
rafa.ben...@gmail.com,
Apr 24 2018
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: 1. Open dev-tools & Network 2. Go to https://www.apple.com/itunes/ 3. Inspect timings for any entry for url image_large.svg 4. Note that the receive time is too large for the small content that is actually sent from server & it increased from previous versions of Chrome. What is the expected behavior? To be consistent with times reported from net-internals or cURL, that report a far less receive time for the same resource. What went wrong? In previous versions seems like this value was correct (like version 55). Seems like timestamp for loadingFinished event has changed. Did this work before? Yes 55~ Chrome version: 65.0.3325.181 Channel: n/a OS Version: OS X 10.12.6 Flash Version:
,
Apr 25 2018
Thanks for filing the issue! Unable to reproduce the issue on reported chrome version 65.0.3325.181 using Mac 10.13.1 with the below mentioned steps. 1. Launched Chrome 2. Navigated to https://www.apple.com/itunes/ 3. Inspected the page -> Network tab 4. Refreshed the page -> Clicked on image_large.svg We are able to see low recorded time in µs rather than in ms. Attaching the screen shot of the same. @Reporter: Could you please have a look at the screen shot and let us know if we have missed anything in the process. Any further inputs from your end may be helpful.
,
Apr 25 2018
Hi, thanks for answer. I think that resource is being cached in your test. Forgot to say that Chrome should open in incognito mode or cache disabled.
,
Apr 25 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 26 2018
Unable to reproduce the issue on reported chrome version 65.0.3325.181 using Mac 10.13.1 with the below mentioned steps. 1. Opened Chrome in incognito mode 2. Navigated to https://www.apple.com/itunes/ 3. Inspected the page -> Network tab 4. Refreshed the page -> Timing -> Clicked on image_large.svg We are able to see low recorded time in µs even in incognito mode. Attaching the screen cast of the same for reference @Reporter: Could you please have a look at the screen cast and let us know if we have missed anything in the process. Any further inputs from your end may be helpful.
,
Apr 26 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 26 2018
After some trials figured out how to attach screencast in mp4. I think, is still cached, you can see it in the Size column: (from cache). I suggest to reproduce the following steps to reproduce the issue: 1. Copy the url: https://www.apple.com/itunes/ 2. Open chrome://net-internals 3. Open dev tools before navigating to https://www.apple.com/itunes/ 4. Verify that 'Disable cache' flag is on in Network panel 5. Paste the url in the browser 6. Inspect the receive time for first entry of image_large.svg 7. Inspect in net-internals that the time to receive the body of that element is almost zero Recorded the steps to reproduce this issue in screencast attached.
,
Apr 27 2018
Able to reproduce the issue on reported chrome version 65.0.3325.181 and on the latest canary 68.0.3409.0 using Windows 10, Ubuntu 14.04 and Mac 10.13.1 with the steps mentioned(screencast provided) in comment#10 by reporter. As the issue is seen from M60(60.0.3112.0) considering it as Non-Regression and marking it as Untriaged and requesting someone from Dev team to have a look into this and help in further triaging it. Hence removing Needs-Bisect label. Attaching the screen shot from M60 for reference. Thanks!
,
May 14 2018
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by krajshree@chromium.org
, Apr 25 2018