New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 872616 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 873860
Owner:
Last visit > 30 days ago
Closed: Aug 22
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression : Vertical scroll bar appears chopped from RHS in devtools.

Reported by rp...@etouch.net, Aug 9

Issue description

Chrome version: 70.0.3517.0 (Official Build)Revision 40b8dc74d4eba316ce85e7c7cb5cac598d17069d-refs/branch-heads/3517@{#1}(32/64-bit)
OS: Windows 10

What steps will reproduce the problem?
1. Launch chrome,navigate to NTP and open devtools,observe vertical scroll bar
 
Actual: Vertical scroll bar appears chopped from RHS
Expected: Vertical scroll bar should be seen properly

This is regression issue, broken in ‘M 70’ and will soon update other info :
Good build: 70.0.3516.0  (Revision: 581410).
Bad build: 70.0.3517.0 (Revision: 581729).
 
Actual_video.mp4
550 KB View Download
Expected_video.mp4
464 KB View Download
Actual_screenshot.png
146 KB View Download
Expected_screenshot.png
149 KB View Download
Labels: Proj-Windows10 hasbisect
Owner: pkasting@chromium.org
Status: Assigned (was: Unconfirmed)
Change Log URL :
https://chromium.googlesource.com/chromium/src/+log/70.0.3516.0..70.0.3517.0?pretty=fuller&n=10000

Suspect : r581538 ?

pkasting@ : Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note : 
1. This is Windows 10 specific issue and same is not reproducible in Linux(14.04 LTS) & Windows (7, 8, 8.1) OS and will soon update Mac info.
2. Unable to provide bisect using per-revision script on Windows machines as it is giving trace back error. 
3. Also tried chromium bisect but it gives "RuntimeError: We don't have enough builds to bisect. revlist: [ ]" . Increased the revision range but still got the same error every time.
4. Hence provided the manual suspect through Change Log URL.

Thank You..!
Cc: pkasting@chromium.org
Owner: tbergquist@chromium.org
Not my change -- this looks like a layout/sizing change rather than simply not painting something.

I'm suspicious of https://chromium-review.googlesource.com/c/chromium/src/+/1149273 -- Taylor, can you check?
I can't repro (though I am on tip of master; I'll try backing up to the referenced commit).

I do see something similar - both before and after my change - where the initial layout after switching DPIs (e.g. when dragging between displays with different DPIs) is wrong in approximately the way described, and it relayouts after a second or two (probably much faster on a release build - maybe within one frame, even).

What is your display setup - one display or more? If more, do you have mixed DPI settings?
With respond to comment #3:

Using Single display and kindly find attached screen shot of Display settings.

Note : Issue is not seen on Mac OS X(10.12.6,10.13.1,10.13.6).
Display_settings_screenshot.png
63.4 KB View Download
@4: That window doesn't show your scaling information.  Can you share what scale you're running at?
With response to comment #6 :
kindly find attached screen shot of Scaling information.
Scaling_information.png
382 KB View Download
Mergedinto: 873860
Status: Duplicate (was: Assigned)

Sign in to add a comment