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

Issue 680369 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: Feb 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Fails to repaint with CSS transition

Reported by ja...@krypton.io, Jan 12 2017

Issue description

Chrome Version       : 55.0.2883.95
OS Version: OS X 10.10.5

What steps will reproduce the problem?
1. Use a macbook retina display
2. React changes className & innerHTML on span element triggering a CSS transition.

What is the expected result?

Old span innerHTML should no longer be rendered.

What happens instead of that?

Old innerHTML content remains painted until a repaint is forced by resizing the window, or toggling the CSS attributes in the debugger.


Please provide any additional information below. Attach a screenshot if
possible.

I'm sorry about repro steps being pretty light. I'm having a hard time creating a minimal repro without sharing our entire app, which I can't really do.

Here is a gif of the problem drawing. https://cl.ly/1j2S3h03201f/Screen%20Recording%202017-01-11%20at%2006.45%20PM.gif
The span contents at the end of the gif in the debugger are 'All Changes Saved' but once the transition fades that out the 'Saving...' text is still left.

The debugger shows this as the CSS, the 'saved' className is added when the content changes to 'All Changes Saved', but this doesn't seem enough to repro.

.content {
    display: -webkit-box;
    display: -ms-flexbox;
    display: flex;
    -webkit-box-orient: horizontal;
    -webkit-box-direction: normal;
    -ms-flex-direction: row;
    flex-direction: row;
    padding: 8px 12px;
    line-height: 1.25;
    font-weight: 400;
    -webkit-box-align: center;
    -ms-flex-align: center;
    align-items: center;
    font-size: 0.8rem;
    color: #757575;
    -webkit-box-flex: 1;
    -ms-flex-positive: 1;
    flex-grow: 1;
    overflow: hidden;
    opacity: 1;
}

.content.saved {
  opacity: 0;
  -webkit-transition: opacity 2s ease-in-out 2s;
  transition: opacity 2s ease-in-out 2s;
}

Additional interesting facts:
- When you drag the chrome window off screen onto an attached monitor the problem goes away.
- After reading this article http://blog.getpostman.com/2015/01/23/ui-repaint-issue-on-chrome/ I added the transform: translate3d(0,0,0); CSS property to the span in question and the issue went away.
- Resizing the window sometimes seemed to suppress the issue.
- React is managing the DOM element modification/replacement.
- Removing the transition CSS property also seems to eliminate the issue.

We think the regression was in the last month or two, but I don't have an exact pin point. I hope that is at least enough details for someone to get pointed in the right direction.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36



 
Cc: rbasuvula@chromium.org
Components: Blink>CSS
Labels: TE-NeedsTriageHelp
This looks like out of scope for TE, hence adding the respective label for it to  triage further.
Labels: Needs-Feedback
Owner: ericwilligers@chromium.org
(BrowserStack would provide you a way to test earlier Chrome versions, and other platforms, but that still wouldn't give us enough information to identify the relevant Chrome code changes.)

We will need a test case.

Once we have a test case, we run a bisect
https://www.chromium.org/developers/bisect-builds-py
to identify a small commit range the led to the change in behavior.

e.g.

curl -s --basic -n "https://chromium.googlesource.com/chromium/src/+/master/tools/bisect-builds.py?format=TEXT" | base64 -d > bisect-builds.py

python bisect-builds.py -a mac -g 200000 -b 442800 --use-local-cache -- --no-first-run --user-data-dir=/tmp http://example.com

Comment 3 by ja...@krypton.io, Jan 13 2017

FYI, you might want to update your documentation slightly on mac base64 -d is debug you need to base64 -D.

Comment 4 by ja...@krypton.io, Jan 13 2017

I bisected the issue on our app and this is what I got:

You are probably looking for a change made after 422671 (known good), but no later than 422685 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/77b42df81a9c802d91dd2575b57d4780df16bf80..f90d946c02ceae301be97b89e746d0c78462996c

Comment 5 by ajha@chromium.org, Jan 16 2017

Cc: ericwilligers@chromium.org
Owner: chrishtr@chromium.org
chrishtr@: Could this be related to https://codereview.chromium.org/2386263002 from the bisect result of C#4.
Project Member

Comment 6 by sheriffbot@chromium.org, Jan 23 2017

Labels: -Needs-Feedback Needs-Review
Thank you for providing more feedback. Adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Pri-3 M-55 Pri-2
Status: Assigned (was: Unconfirmed)
Cc: ja...@krypton.io
I can't see anything in that bisect range which would cause the symptoms of this bug.

Bug reporter: I can mark this bug as restricted to Google employees only. Would you then
be comfortable sharing the actual testcase which reproduces the bug?

Comment 9 by suzyh@chromium.org, Jan 24 2017

Labels: Needs-Feedback
Labels: Hotlist-Interop
Status: WontFix (was: Assigned)
Going to close this bug based on no feedback since Jan 23 or reduced testcase.
Please comment on the bug if you have an update.

Sign in to add a comment