CSS transform + clip-path causes incorrect clipping
Reported by
da...@davidmurdoch.com,
Feb 7 2018
|
|||||
Issue descriptionChrome Version : 64.0.3282.140 OS Version: 10.0 URLs (if applicable) : http://jsbin.com/verubipejo/ Other browsers tested: Chrome 63.0.3239.132: OK What steps will reproduce the problem? 1. Visit http://jsbin.com/verubipejo/ 2. In Chrome 64, see how `clip-path` + `calc` does not correctly measure the element's dimensions, which then incorrectly clips the element 3. Check the same in Chrome 63, where the `clip-path` is correct. What is the expected result? Adding a CSS `transform` to an element should not affect the way `clip-path` clips the element. What happens instead of that? Adding a CSS transform (even one that doesn't change/move anything) causes the clip-path to be calculated incorrectly. Please provide any additional information below. Attach a screenshot if possible. Originally discovered in the drop down menus at https://www.strombeck.com UserAgentString: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36
,
Feb 13 2018
Able to reproduce this issue on reported version 64.0.3282.140 and on latest beta 65.0.3325.51 using windows 10, Ubuntu 14.04 and Mac 10.13.3 . But issue is fixed on latest canary 66.0.3346.0. Hence providing reverse bisect info. NOTE: Issue is seen in latest stable 64.0.3282.167 as well. Last Bad Build: 66.0.3334.0 First Good Build: 66.0.3335.0 You are probably looking for a change made after 532649 (known good), but no later than 532650 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/e34e01b1b0987e418bc22e3ef1cf2e4ecaead264..f89ae106e06d15200d783cb6950961ba999edebe Probably fixed by https://chromium-review.googlesource.com/858299. @ trchen: Please let us if it safe to merge to M-64 and M-65. Adding RB-Stable for M-64. Please remove if not the case.
,
Feb 13 2018
Able to reproduce this issue on reported version 64.0.3282.140 and on latest beta 65.0.3325.51 using windows 10, Ubuntu 14.04 and Mac 10.13.3 . But issue is fixed on latest canary 66.0.3346.0. Hence providing reverse bisect info. NOTE: Issue is seen in latest stable 64.0.3282.167 as well. Last Bad Build: 66.0.3334.0 First Good Build: 66.0.3335.0 You are probably looking for a change made after 532649 (known good), but no later than 532650 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/e34e01b1b0987e418bc22e3ef1cf2e4ecaead264..f89ae106e06d15200d783cb6950961ba999edebe Probably fixed by https://chromium-review.googlesource.com/858299. @ trchen: Please let us if it safe to merge to M-64 and M-65. Adding RB-Stable for M-64. Please remove if not the case.
,
Feb 13 2018
Yes I confirm part of the goal of that CL is to fix this bug. However it will be difficult to merge even manually. The CL is quite complex itself and depends on other complex CLs. (It also introduced one top crash bug that has a fix pending.) It is curious why M63 wasn't affected by this bug. I thought this issue long existed since the introduction of threaded scrolling.
,
Feb 13 2018
[Auto-generated comment by a script] We noticed that this issue is targeted for M-64; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-64 label, otherwise remove Merge-TBD label. Thanks.
,
Feb 13 2018
Seems like no merge to M64 & M65 based on comment #4. So removing "Merge-TBD" label. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by susanjun...@techmahindra.com
, Feb 7 2018