New issue
Advanced search Search tips

Issue 906496 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 16
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Scrollbar is broken under "left: 50%; translateX(-50%);"

Reported by potassiu...@gmail.com, Nov 19

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36

Example URL:
http://sinst.html.xdomain.jp/zengaku/jkkn/chrome_bug10.html

Steps to reproduce the problem:
1. Center a box by "position: relative; left: 50%; transform: translateX(-50%);".
2. Apply odd number of pixel as the width of the box (e.g.: "width: 201px").
3. Let scrollbar appear

What is the expected behavior?
The scrollbar is displayed as usual

What went wrong?
When the width of the box has odd number of pixel, scrollbar is splitted by several ugly cracks.

Please try resizing the box on http://sinst.html.xdomain.jp/zengaku/jkkn/chrome_bug10.html

Screenshot is attached:

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 70.0.3538.102  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

* Maybe it's a problem of subpixels, but I guess they've already dealt with this problem on div boxes themselves, but not yet on scrollbars.

* Strangely enough, it doesn't occur with translateX(-49%) or translateX(-51%). It occurs only when the percentage is 50.

* The cracks disappear when I use translate3d in place of translate, but text-content becomes terribly blurred if the width is wide enough and the scrollbar is gone.
So it's not a good workaround of this issue.
(What is worse, the cracks no longer disappears even I use translate3d in Chrome Canary 72.0.3614.0)
 
chrome_bug10.png
44.9 KB View Download
Mistake:
Wrong:     left: 50%; translateX(-50%);
Correct:    left: 50%; transform:translateX(-50%);
Labels: Needs-Triage-M70
Components: -Blink Blink>Scroll
Cc: swarnasree.mukkala@chromium.org
Labels: -Type-Bug -Pri-2 RegressedIn-62 hasbisect-per-revision Triaged-ET Target-70 Target-71 Target-72 M-72 FoundIn-71 FoundIn-70 FoundIn-72 Pri-1 Type-Bug-Regression
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on reported chrome version #70.0.3538.102 and latest chrome #72.0.3615.0 using Windows 10 by following steps as per comment#0.The following is bisect information.
Note: Issue is not seen on Mac OS and Linux.

Bisect Information:
==============
Good Build: 62.0.3176.0
Bad Build: 62.0.3177.0

Change Log: https://chromium.googlesource.com/chromium/src/+log/1ca1d303d8c55d0b079cd8f3504fbb9835fc4b54..6756bd6774abc6149e65f5fb55854ab4973e3bbe
Skia-deps-roller Change Log :https://skia.googlesource.com/skia.git/+log/5910ed347a63..121ad19a7ece

Unable to find the correct suspect from the above change log hence marking it as untriaged. Requesting someone from Blink>Scroll to help us in assigning the issue
Thanks.!
Cc: bokan@chromium.org mtklein@chromium.org
Components: -Blink>Scroll Internals>Skia
Owner: robertph...@google.com
Status: Assigned (was: Untriaged)
Looks like pixel snapping issue so the bisect makes sense. I suspect it's:

Update SkClipStack's bound computation

But +cc both CL authors.

Comment 6 Deleted

I've found that centering has nothing to do with this issue, and it is always caused by "translateX(0.5px)".
Simpler sample:
http://sinst.html.xdomain.jp/zengaku/jkkn/chrome_bug10_.html
Cc: fmalita@chromium.org
Here is a Skia fiddle that more directly demonstrates the issue:

https://fiddle.skia.org/c/e0062438cca5c8379dca827d186ea2a8

In short, non-AA rects are being drawn through non-AA rect clips with a non-integer translation.
Project Member

Comment 9 by bugdroid1@chromium.org, Jan 9

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/9548c3b42ffaefa27541c987ef34ba8491abb584

commit 9548c3b42ffaefa27541c987ef34ba8491abb584
Author: Robert Phillips <robertphillips@google.com>
Date: Wed Jan 09 21:35:30 2019

No longer round the non-AA clip bounds

By no longer rounding the non-AA clip bounds we increase the probability that a non-AA clip will be dropped when applied to a non-AA rect draw (particularly at half pixel translations).

To make this work in practice we must also make the clip stack check if the non-AA clip is relevant before we preemptively employ a scissor clip.

Note that I have verified that this removes the gross clipping errors from the Chrome repo case but the rounding to scissor clip behavior could still happen in other cases.

Bug:  906496 
Change-Id: Iba51b9061fb434144e3a9b3fd91479109fcf67f4
Reviewed-on: https://skia-review.googlesource.com/c/182141
Reviewed-by: Michael Ludwig <michaelludwig@google.com>

[modify] https://crrev.com/9548c3b42ffaefa27541c987ef34ba8491abb584/src/core/SkClipStack.cpp
[modify] https://crrev.com/9548c3b42ffaefa27541c987ef34ba8491abb584/src/gpu/GrRenderTargetOpList.cpp
[modify] https://crrev.com/9548c3b42ffaefa27541c987ef34ba8491abb584/src/gpu/GrReducedClip.cpp

Project Member

Comment 10 by bugdroid1@chromium.org, Jan 10

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/eb4ceeddc3172e444b1b0e2c9c72389db8ca6378

commit eb4ceeddc3172e444b1b0e2c9c72389db8ca6378
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Thu Jan 10 03:43:46 2019

Roll src/third_party/skia a7b2874b86e0..d2fa7e33798c (7 commits)

https://skia.googlesource.com/skia.git/+log/a7b2874b86e0..d2fa7e33798c


git log a7b2874b86e0..d2fa7e33798c --date=short --no-merges --format='%ad %ae %s'
2019-01-10 recipe-roller@chromium.org Roll recipe dependencies (trivial).
2019-01-09 herb@google.com Make pointers to glyphs in the SkGlyphCache stable
2019-01-09 robertphillips@google.com No longer round the non-AA clip bounds
2019-01-09 halcanary@google.com Docs: drawText -> drawSimpleText
2019-01-09 halcanary@google.com tools: Remove sk_tool_utils::set_portable_typeface()
2019-01-09 halcanary@google.com drawText Cleanup, part 6
2019-01-09 skia-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/externals/angle2 4f3b207d049a..b5ba549abf2f (3 commits)


Created with:
  gclient setdep -r src/third_party/skia@d2fa7e33798c

The AutoRoll server is located here: https://autoroll.skia.org/r/skia-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux-blink-rel;luci.chromium.try:linux-chromeos-compile-dbg;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel

BUG= chromium:906496 
TBR=bsalomon@chromium.org

Change-Id: I3a10167e440551c784561dd9c09eceac1ec14a93
Reviewed-on: https://chromium-review.googlesource.com/c/1403964
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#621442}
[modify] https://crrev.com/eb4ceeddc3172e444b1b0e2c9c72389db8ca6378/DEPS

Comment 11 by robertph...@google.com, Jan 16 (6 days ago)

Status: Fixed (was: Assigned)

Comment 12 by robertph...@google.com, Jan 16 (6 days ago)

Cc: michaelludwig@google.com

Sign in to add a comment