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

Issue 772724 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Oct 23
Cc:
█ vollick@chromium.org
ccameron@chromium.org
vmp...@chromium.org
Components:
EstimatedDays: ----
NextAction: 2017-11-23
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Rendering glitches with overlapping elements on overflow scrolling divs

Reported by ian.voll...@gmail.com, Oct 8 2017 
UserAgent: Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_3 like Mac OS X) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.0 Mobile/14G60 Safari/602.1

Example URL:
smfr.org/misc/css/stacking/css-escher.html

Steps to reproduce the problem:
1. If you scroll the contents of the overflow scrolling div, the blue divs will change colour as the overlap the position fixed green div.

What is the expected behavior?
The blue elements should not change color.

What went wrong?
The blue elements seem to change color subtly as they move. To be clear they snap between two colors, a lighter one and a darker one depending on, it seems, how they overlap, but perhaps the overlap is unrelated

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: 61.0.3163.100  Channel: stable
OS Version: 
Flash Version:

Comment 1 by ian.voll...@gmail.com, Oct 8 2017 

The device was low-dpi, and turning on layer borders showed that whenever the layer contained more than just a single blue div, the color was incorrect. Not sure if this is a squashing, painting or compositing issue. If I had to guess, I'd look at whether compositing behaved differently when the layers switched from being opaque (containing just the blue div), and partially transparent. It's worth noting that the green div below the blue ones does not show through the blue divs when they draw in their "lighter" state. I.e., I don't think it's a simple opacity bug.

Comment 2 by ian.voll...@gmail.com, Oct 8 2017 

Also, I do *not* see this issue on a low-dpi chromebook at 60.0.3112.114.

Comment 3 by nyerramilli@chromium.org, Oct 9 2017

Labels: Needs-Triage-M61

Comment 4 by schenney@chromium.org, Oct 9 2017

Cc: ccameron@chromium.org
Components: -Blink Blink>Compositing Blink>Paint
Labels: Needs-Feedback
NextAction: 2017-10-23
What happens if you disable color correction that shipped in M-61? This sounds a lot like issues we have seen there, particularly given the subtle color shifts.

Otherwise it's a compositing bug.

Comment 5 by monor...@bugs.chromium.org, Oct 23 2017 

The NextAction date has arrived: 2017-10-23

Comment 6 by vollick@chromium.org, Oct 23 2017

Labels: -Needs-Feedback
Unfortunately, I no longer have access to this machine and cannot check.

Comment 7 by vollick@chromium.org, Oct 23 2017

Cc: vollick@chromium.org

Comment 8 by schenney@chromium.org, Oct 23 2017

NextAction: 2017-11-23
Status: Available (was: Unconfirmed)
Need to look into reproducing this but not urgent. Doesn't repro on Linux.

Comment 9 by monor...@bugs.chromium.org, Nov 23 2017 

The NextAction date has arrived: 2017-11-23
Project Member

Comment 10 by sheriffbot@chromium.org, Oct 23

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

Comment 11 by schenney@chromium.org, Oct 23

Status: WontFix (was: Untriaged)
I think this is WontFix. Can't reproduce on Mac.
►

Sign in to add a comment