DevTools: cannot scroll to bottom in Network when zoomed or on super high resolution
Reported by
patrick....@anyconnect.com,
May 17 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce the problem: 1. Open Chrome Developer Tools 2. Navigate to Network Tab 3. Perform enough requests to overfill list 4. Attempt to scroll to bottom What is the expected behavior? As a developer, I expect the Waterfall rows to line up properly with the request that has been made. What went wrong? Waterfall row heights are different than the list of requests, after enough requests, the difference can become large enough to offset the rows by 1 (can be viewed when hovering over rows). If the waterfall rows are shorter than the main request rows, the scrollbar will NOT scroll farther than the waterfall column, blocking the developer from inspecting any more requests. Did this work before? N/A Chrome version: 57.0.2987.133 Channel: n/a OS Version: 10.0 Flash Version: The height appears to change based on resolution: out of the 2 resolutions I have tested (both monitors in use at same time), 1920x1080 (primary) monitors the waterfall rows are larger than the main rows, 3840x2160 (secondary) monitors the waterfall rows are shorter than the main rows.
,
May 18 2017
Version 60.0.3103.0 (Official Build) canary (64-bit) The issue no longer occurs with a 1920x1080 resolution. After a clean install of Google Chrome Canary (uninstalled Chrome, deleted all leftover data from Program Files and AppData) spacing issue still occurs with a 3840x2160 resolution, the scrollbar is no longer jumpy, though it still only scrolls to the shortest height (cutting off request as before). Was able still able to replicate with second screen only option on Windows 10 Home, version 1703, OS Build 15063.296 (machine is a laptop, unable to remove 1920x1080 monitor). I have attached a few screenshots, one with the dev tools maximized, and the other reduced to a random width and height to show scrolling issue: scroll is on the bottom in both captures.
,
May 18 2017
Note: All non-google extensions were disabled Enabled extensions: Google Docs 0.9 Google Docs Offline 1.4 Google Sheets 1.1 Google Slides 0.9
,
May 19 2017
Still present in Version 60.0.3104.0 (Official Build) canary (64-bit)
,
May 23 2017
Still present in Version 60.0.3108.0 (Official Build) canary (64-bit)
,
May 30 2017
Still present in Version 61.0.3115.0 (Official Build) canary (64-bit) (Note I will be updating this roughly every week or so in hopes to keep this on the radar)
,
Jun 9 2017
Version 61.0.3124.10 (Official Build) canary (64-bit)
,
Jun 20 2017
Version 61.0.3135.4 (Official Build) canary (64-bit) The resolution this occurs on is 3840x2160 if it was not clear
,
Jul 20 2017
,
Nov 30 2017
Seeing this also. I notice that it works fine at the default zoom state. But at most other zoom states, I see the incorrect row heights. Attached another screenshot in case it's helpful.
,
Dec 14 2017
,
Dec 14 2017
,
Dec 14 2017
,
Dec 14 2017
,
Dec 14 2017
Issue 767780 has been merged into this issue.
,
Dec 14 2017
Issue 771358 has been merged into this issue.
,
Dec 29 2017
Issue 773999 has been merged into this issue.
,
Dec 29 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4c1c5baa34e643d8cd299bf4e7b10c02f9b20adc commit 4c1c5baa34e643d8cd299bf4e7b10c02f9b20adc Author: Erik Luo <luoe@chromium.org> Date: Fri Dec 29 22:33:07 2017 DevTools: fix rounding in Network row heights Network's viewport uses row heights to determine maximum scrollTop. 'rawRowHeight' is 21 CSS px, but under other zoom/scale conditions, can vary between 20 (zoomed in) and 22 (zoomed out) since the browser must render to physical pixels. Using devicePixelRatio with Math.floor() accounted for the former case, but not the latter. Incorrect row height calculations led to Network being unable to scroll to the bottom. This CL fixes the rounding issue. Bug: 723789 Change-Id: I9de813d49c3fb1b92cb0f7bc057395804bcbfc8a Reviewed-on: https://chromium-review.googlesource.com/840735 Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Erik Luo <luoe@chromium.org> Cr-Commit-Position: refs/heads/master@{#526395} [modify] https://crrev.com/4c1c5baa34e643d8cd299bf4e7b10c02f9b20adc/third_party/WebKit/Source/devtools/front_end/network/NetworkLogView.js [modify] https://crrev.com/4c1c5baa34e643d8cd299bf4e7b10c02f9b20adc/third_party/WebKit/Source/devtools/front_end/network/NetworkWaterfallColumn.js
,
Dec 31 2017
The fix above has landed on the Canary channel. Canary users should now be able to scroll to the bottom, please comment here if you are still unable to. If the fix goes well for a day or so, we could request merging this to M64.
,
Jan 2 2018
Verified the issue on 65.0.3309.0 using Windows 10 with different resolutions 3840x2160 , 1366x768 and with different zoom levels and different dock positions and is no longer reproducible with steps mentioned below. 1.Launched chrome and navigated to https://bugs.chromium.org/p/chromium/issues/detail?id=723789 , opened devtools network tab. 2. Reloaded page and observed sufficient network results to scroll 3. Able to scroll till end and observed last network request without any chop. Hence the fix is working as expected, adding TE-Verified labels.
,
Jan 2 2018
I do not see lines chopped, but I still see the thumb is not at bottom Version 65.0.3300.0 (Official Build) canary (64-bit)
,
Jan 2 2018
Comment #20 looks like expected behavior to me. Thanks for verifying. Comment #21 does not look correct to me. Your version (65.0.3300.0) corresponds to commit 525555, which does not include the fix (commit 526395) noted in comment #18. Commenter #21, could you please try your setup on Chrome version 65.0.3309.0 or later?
,
Feb 7 2018
Issue 809407 has been merged into this issue.
,
Jun 26 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by l...@chromium.org
, May 18 2017Status: Assigned (was: Unconfirmed)