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

Issue 758571 link

Starred by 20 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

semi-transparent div becomes partly invisible after being overlapped with other element

Reported by nikita.u...@gmail.com, Aug 24 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Example URL:
https://jsfiddle.net/cgg6jz5x/

Steps to reproduce the problem:
1. Launch Chrome
2. Open https://jsfiddle.net/cgg6jz5x/
3. Drag the green square over the orange rectangle several times

What is the expected behavior?
The orange div is rendered as solid rectangle, the white div underneath is not visible

What went wrong?
Parts of the orange rectangle become invisble allowing the white div underneath to be seen 

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? Yes 58.0.3029.110

Does this work in other browsers? Yes

Chrome version: 60.0.3112.101  Channel: stable
OS Version: 10.0
Flash Version: 

The issue is not reproduced if either white or orange div have an opacity set to 1 or optimized with "will-change"
 
2017-08-24_1704.png
136 KB View Download
The problem is not reproduced if either "position" or "overflow" declaration for rule

.layers {
    height: 100%;
    position: relative;
    overflow: hidden;
}

is removed from source code
Labels: Needs-Triage-M60 Needs-Bisect

Comment 3 by hdodda@chromium.org, Aug 25 2017

Cc: hdodda@chromium.org
Components: Internals>GPU>Rasterization
Labels: -Pri-2 -Type-Compat -Needs-Bisect hasbisect-per-revision M-60 Pri-1 Type-Bug-Regression
Owner: ericrk@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue only on windows 10 using chrome M60 #60.0.3112.113 and M62 #62.0.3194.0 .

This is a regression issue broke in M60 and is reproducible only in windows 10.

Using the per-revision bisect providing the bisect results,
Good build: 60.0.3181.0 (Revision:467188).
Bad build: 60.0.3182.0 (Revision:467199.

You are probably looking for a change made after 467197 (known good), but no later than 467198 (first known bad).

CHANGELOG URL:

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

 https://chromium.googlesource.com/chromium/src/+log/f91ad00d0d78fe00a5d1ca4fc50ace6cd63718a7..4166ab857753a66e9ba6aea475ada0f14b0971d8

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

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

Review-Url: https://codereview.chromium.org/2844483003

Thanks!
Labels: Hotlist-Interop
Labels: -Needs-Triage-M60
Hello,

With v61 update, the bug is reproducing even on a page load, without moving a mouse. Please see the attached screencast.
Thanks.
chrome-61.gif
1.7 MB View Download

Comment 7 by ericrk@chromium.org, Oct 27 2017

Cc: ericrk@chromium.org
Owner: hdodda@chromium.org
I expect this is the same as  issue 770701 . Per manoranjanr@'s comments in  issue 770701 , this should be fixed in M64. hdodda@, as you were able to successfully repro this before, can you confirm the fix in the latest (M64) Canary? Thanks!

Comment 8 by piman@chromium.org, Feb 26 2018

Status: Fixed (was: Assigned)
GPU triage: closing issue. Please reopen if it still happens.

Sign in to add a comment