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

Issue 721097 link

Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 722368
Owner:
Last visit > 30 days ago
Closed: May 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Reseting 'transform' and 'will-change' after transition of transform property causes misalignment

Reported by m...@stephan.is, May 10 2017

Issue description

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

Example URL:
http://output.jsbin.com/zorofanamo

Steps to reproduce the problem:
1. Open the example URL
2. Wait for the animation to complete
3. Wait for the transformation to be removed
4. Click (multiple times) anywhere to force rerendering and correct positioning by hiding and showing the elements

What is the expected behavior?
The position of the green boxes should remain relative to the surrounding black container even if the transformation property is reset.

What went wrong?
The container is animated using a css translate transform, the will-change property is set as well. After completion of the animation, the transform property as well as the will-change property are reset to their default values. This causes the elements with position absolute to be positioned incorrectly. Forcing a redraw by hiding and showing the elements (multiple times) restores correct positioning. 

As far as I can tell the issue seems to be related with layer creation and combination, as it is required that the black box is promoted to a separate layer. The issue first occured on one of the websites we are developing. 

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes 57

Does this work in other browsers? Yes

Chrome version: 58.0.3029.110  Channel: stable
OS Version: OS X 10.12
Flash Version: Shockwave Flash 25.0 r0

It does not happen in Chrome 56 or 57. It happens most of the times in Windows 10 Chrome 58.0.3029.110 as well.
 
Labels: Needs-Triage-M58 OS-Windows

Comment 2 by m...@stephan.is, May 11 2017

Unfortunately it seems to be not always reproducible (even on the same device), but it occurs on Windows as well as MacOS. I just create a second testpage (in case the jsbin example is not available): http://www.stephan.is/reporting/chromium/721097/index1.html

Comment 3 by bokan@chromium.org, May 16 2017

Components: -Blink Blink>Compositing
I can repro reliably on a MBP w/retina with 58.0.3029.110 but not on Linux. Suggests a compositing issue to me. Screen shot of problem case attached.
Screen Shot 2017-05-16 at 10.55.53 AM.png
971 KB View Download
Labels: Needs-Bisect
Labels: -Type-Bug -Pri-2 -Needs-Bisect has-bisect-per-revision M-58 OS-Linux Pri-1 Type-Bug-Regression
Owner: wkorman@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on windows 7, Ubuntu 14.04 and Mac 10.12.4 using chrome version 58.0.3029.110 and this is working fine on canary 60.0.3102.0
Please find the reverse bisect information as below

Narrow Bisect::
Good :: 59.0.3049.0  ---   (build revision 458956)
Bad:: 59.0.3048.0  --   (build revision 458590)

Change Log::
https://chromium.googlesource.com/chromium/src/+log/a0ca178033ce1a45919921fa67a050b808d706de..463b2dfe64df899fda4359f2d360ee1cba46e26b

Possible CL that fixed this issue might be
https://chromium.googlesource.com/chromium/src/+/463b2dfe64df899fda4359f2d360ee1cba46e26b

wkorman@ Please check this issue and merge the fix to M58.

Thanks,


Mergedinto: 722368
Status: Duplicate (was: Assigned)

Sign in to add a comment