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

Issue 760995 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-10-02
OS: Mac
Pri: 2
Type: Compat



Sign in to add a comment

Chrome shows white patches after fade in animation

Reported by pie.or....@gmail.com, Aug 31 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0

Example URL:

Steps to reproduce the problem:
This is an internal site so I can't unfortunately give you a repo, I will try to explain what happens and can provide a video demoing the problem: https://youtu.be/ohuI3BnBj8Y

What is the expected behavior?

What went wrong?
When the page loads it does a simple fade in animation. After that animation the page has white patches.
These white patches disappear after a full layout like changing the viewport size.

In the devtools, performance tab the screenshots capture the same thing with the page rendering correctly during the animation and just when the animation ends and chrome does recalculate style followed by a layout the white patches appear.

If I pause the animation, the patches does not appear until I resume the animation and it ends.

Due to legacy code the animation is done both on the container and a few child elements. If the animation is removed on everything but the container, the white patches does not appear.

I have attached a timeline profile.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? Yes 59

Does this work in other browsers? Yes

Chrome version: 60.0.3112.113  Channel: stable
OS Version: OS X 10.12
Flash Version: 26.0.0.151
 
Profile-20170831T171052
21.5 MB Download
Cc: hdodda@chromium.org
Labels: Needs-Triage-M60 Needs-Feedback
@pie.or.paj-- Thanks for reproting the issue.

Could you please try providing the sample jsfiddle/codepen to reproduce the issue , with out any repro we will be unable to triage the issue better.

Thanks!

Comment 2 by shrike@chromium.org, Sep 15 2017

Components: Blink
[mac bug triage] -> blink queue
Components: -Blink Blink>Paint
NextAction: 2017-10-02
Just to re-iterate, if this broke due to an M-60 update we will need a public test case to perform a bisect to identify the breaking change. We cannot proceed otherwise.

Also, could you please test Chrome Canary and see if it has the same behavior.
I understand you need a repo. This is an internal application so I saved the page and removed some privet information from it, however the bug still appears.

The bug seems to be gone in Canary
Archive.zip
57.7 KB Download
Project Member

Comment 6 by sheriffbot@chromium.org, Sep 19 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
The bug seems to be gone in 61 as well.
Owner: schenney@chromium.org
Status: Assigned (was: Unconfirmed)
Thanks for helping us out. I'm sorry that the tone of my previous comment was too sharp.

Given that it is fixed in M-61 we will close the bug because M-61 is rolling not now and we are not patching M-60. But I'll wait a week or so in case it re-appears or shows up on some other machine. Let us know if you see any M-61 issues.
The NextAction date has arrived: 2017-10-02
Status: WontFix (was: Assigned)
Marking WontFix (happened to get fixed in M-61) based on comment c#7 and given M-61 roll out.

Sign in to add a comment