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

Issue 773598 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Regression : Unwanted white line is observed on horizontal scroll bar for www.zomato.com.

Reported by rp...@etouch.net, Oct 11 2017

Issue description

Version: 62.0.3202.52 d6ed027fa2ac4051e8fd20a916a8df4350c22986-refs/branch-heads/3202@{#653}
OS: Windows (7,8,8.1,10)
URL : https://www.zomato.com/mumbai/zayna-uber-dining-airoli-navi-mumbai

What steps will reproduce the problem?
1. Launch chrome, navigate to above url.
3. Now scroll down the page and click on any photo under photos and observe clearly horizontal scroll bar besides photo

Actual: Unwanted white line is observed on horizontal scroll bar
Expected: Unwanted white line is should not be present on horizontal scroll bar

This is regression issue, broken in ‘M 62’ and will soon update other info :
Good build:62.0.3176.0
Bad build: 62.0.3177.0

Note 1. Issue is not seen on Mac and Linux OS.
     2. The above issue is resolution specific and is seen on Desktop having resolution of 1280 x 1024 
 
Actual_video.mp4
929 KB View Download
Expected_video.mp4
783 KB View Download
Actual_screenshot.png
743 KB View Download
Expected_screenshot.png
746 KB View Download

Comment 1 by rp...@etouch.net, Oct 11 2017

Labels: hasbisect-per-revision
Owner: robertphillips@chromium.org
Status: Assigned (was: Unconfirmed)
Using the per-revision bisect providing the bisect results,
Good build: 62.0.3176.0 (Revision: 491884).
Bad build: 62.0.3177.0 (Revision: 492183).

You are probably looking for a change made after 492046 (known good), but no lat
er than 492047 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.

https://chromium.googlesource.com/chromium/src/+log/1ca1d303d8c55d0b079cd8f3504fbb9835fc4b54..6756bd6774abc6149e65f5fb55854ab4973e3bbe

From the CL above, assigning the issue to the concern owner 

@robertphillips- 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.

Suspect : https://skia.googlesource.com/skia.git/+/121ad19a7ecefa6fc814cfc24d2625df2178b61c

Thanks!
Cc: fmalita@chromium.org
In the provided case both the horizontal and vertical sliders are drawn with two abutted non-anti-aliased rectangles. As can be seen in the attached .skps, both the clips and rectangles have integer coordinates so Ganesh should abut the non-AA rectangles correctly. In fact, rendering the .skps locally does result in the correct appearance.

Since these are layers, can Chrome ever draw them with a different scale factor? If the layer was drawn with a scale it is possible that the non-AA rects could snap differently (under the influence of the current transformation matrix).
bug773598.skp
8.9 KB Download
bug773598-2.skp
4.1 KB Download
Cc: bsalo...@google.com
I tend to agree that this is probably Chrome snapping in a way that was hidden before the Skia change. I'll look at it when I get to a Windows machine.

Comment 5 by hcm@google.com, Oct 11 2017

Cc: hcm@chromium.org
Owner: ----
Status: Available (was: Assigned)
Removing myself as owner for now, since I don't believe this is a Skia issue.
Labels: -Pri-1 Pri-2
Project Member

Comment 8 by sheriffbot@chromium.org, Nov 14

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Available (was: Untriaged)

Sign in to add a comment