Issue metadata
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 descriptionUserAgent: 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.
,
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
,
May 16 2017
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.
,
May 17 2017
,
May 18 2017
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,
,
May 18 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, May 10 2017