Invalid behavior of 'will-change' property
Reported by
rumyants...@gmail.com,
Apr 6 2016
|
||||||||
Issue descriptionChrome Version : 51.0.2700.0 canary (64-bit) URLs (if applicable) : http://codepen.io/RumyantsevMichael/pen/RajZLe Other browsers tested: Safari: v9.1 - OK Opera: v36 - FAIL Firefox: v47.0a2 - FAIL IE: not supported Edge: not supported What steps will reproduce the problem? (1) DOM element with "will-change: transform" property (2) child element with "position: absolute" What is the expected result? The child element must be positioned relative to the document body. What happens instead? The child element is positioned relative to its parent.
,
Apr 7 2016
Tested the issue on Windows 7, Mac 10.10.5, Ubuntu 14.04 using 51.0.2700.0, latest canary 51.0.2701.0 with below steps: 1.Opened URL: http://codepen.io/RumyantsevMichael/pen/RajZLe 2.Hovered the cursor on 'Hover me'. 3.Observed that red square is seen on hover me inside the box in chrome and firefox. 4.Observed that nothing happened when hovered the cursor on 'Hover me' inside the box in safari. Please find attached screencast. rumyantsev.michael@Could you please provide expected behavior screencast for further triaging the issue.
,
Apr 14 2016
Tested the issue on Windows 7, Mac 10.10.5, Ubuntu 14.04 using 51.0.2700.0, latest canary 52.0.2702.2, stable 50.0.2661.75, beta 50.0.2661.75, dev 51.0.2704.4 as per steps in comment #1. Observed the behavior as below: 1.Observed that red square is seen on 'Hover me' when hovered inside the box in chrome and firefox. 2.Observed that nothing happened when hovered the cursor on 'Hover me' inside the box in safari. rumyantsev.michael@Could you please provide the expected behavior for better understanding the issue to triage it further.
,
Apr 17 2016
I think the correct behavior in Safari.
,
Apr 18 2016
Able to reproduce the issue on Windows 7, Mac 10.10.5, Ubuntu 14.04 using 51.0.2700.0, latest canary 52.0.2710.0, stable 50.0.2661.75 as per steps in comment 2. This is regression issue broken in M-36. Please find below bisect info: Last good build:36.0.1948.0 First bad build:36.0.1950.0 CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/d9d942358cb7031681fa8a10924d69e308243e65..f0e87a679aa6d8643079250b90c9865c2b585aa6 BLINK CHANGELOG URL: http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=171874%3A171871 MANUAL BLINK CHANGELOG URL: https://chromium.googlesource.com/chromium/blink/+log/d659a2d8aa5ecbb8f535d2b9bdc346257f9e5cd2..181ff5dcbf6852fac235233f63c936a2ff7be9ff?pretty=fuller&n=10000 From above CL, suspecting below: https://chromium.googlesource.com/chromium/blink/+/239421ef9b505c16d2cf5c9e3bae31648808d22d ajuma@Could you please look into this issue if it is related to your change, else feel free to assign it to an appropriate dev person. @Could you please look into this issue if it is related to your change, else feel free to assign it to an appropriate dev person.
,
Apr 18 2016
This behavior is required by the spec (https://drafts.csswg.org/css-will-change/): "If any non-initial value of a property would cause the element to generate a containing block for absolutely positioned elements, specifying that property in will-change must cause the element to generate a containing block for absolutely positioned elements." Since non-initial values of 'transform' establish a containing block for absolutely positioned elements, so does 'will-change: transform'. The idea is that once you've set 'will-change: transform' on an element, setting a non-initial value of transform just involves sliding that element's subtree around, not moving it relative to its children (in other words, instead of having to re-layout, we just move the composited layer corresponding to that element). |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by ligim...@chromium.org
, Apr 6 2016