Adding "transform: skew(90deg);" to any element stops tab content from re-painting
Reported by
v...@webflow.com,
Jan 5 2017
|
|||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: 1. Go to http://codepen.io/callmevlad/pen/0b7352ba1baaa0f7eba4689065ad3c49 2. Click on the Blue Box that says "Click Me" What is the expected behavior? The blue box should skew to 90degrees (essentially become invisible). Here's an approximation that shows it at 89deg which works correctly: http://codepen.io/callmevlad/pen/38c66a8a0a73a408af1f754aa8514ebb What went wrong? After "transform: skew(90deg)" is applied to the blue box, the entire browser tab just stops painting/rendering. It looks like user interaction still works (e.g. hovering over what should be the rotating red box still shows the custom "?" cursor as if the box was still rotating). The same bug occurs if "transform: skew(90deg);" is added to the CSS directly (e.g. not via the "style" attribute). Refreshing the tab doesn't work - the only way to get back to the page seems to be to copy-paste the URL into a new tab :\ Did this work before? N/A Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.12.2 Flash Version: Shockwave Flash 24.0 r0 Works fine in latest Firefox Stable.
,
Jan 5 2017
Fantastic test cases. Thank you. I can reproduce on Mac and Android. Over to compositing for triage.
,
Jan 6 2017
Able to reproduce the issue on Mac 10.12.2,Win 10 and Ubuntu 14.04 using 55.0.2883.95/87 and canary 57.0.2973.0. Bisect info: ============ Good:55.0.2881.0 Bad :55.0.2882.0 You are probably looking for a change made after 423242 (known good), but no later than 423243 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/cc546ec69b9f577b98818e3be6489e89e4fd9ef1..8c14bf7d37bec879a5caa162f2c72a303da1a6e0 enne@: Could you please take a look into this if its related to your change.
,
Jan 6 2017
,
Jan 9 2017
As an interesting note, if you remove the animation you can successfully skew(90) and then continue.
,
Jan 9 2017
👆 Huh, you're right! This was a reduced case I created from our way more complicated app (Webflow.com) where we have a plethora of CSS animations in other parts of the app - seems that the animation can be anywhere on the page or added to any element (as far as I can tell) to trigger this issue. Also, it's any animating element, even if it's triggered via a transition. For example, here's a pen with the rotation happening as a result of a :hover transform that just takes a while - the bug still occurs: http://codepen.io/callmevlad/pen/4da2857935d056f14d7d7cbe3ba5509a In the example above, note that performing the skew first leaves the painting responsive - but as soon as you trigger the animation (by hovering the red box) everything just freezes and stops painting.
,
Jan 10 2017
Wow. Thanks for this test case. Appears to be mysteriously from this patch, somehow? https://codereview.chromium.org/2252543002
,
Jan 13 2017
Side note: transitioning past `skew(90deg)` doesn't seem to trigger this bug: http://codepen.io/callmevlad/pen/80b137245641deedef5f327e21115c07
,
Jan 13 2017
This happens due to a damage calculation that ends up pushing the limits of integer bounds. I'm currently working on a fix that if we detect a situation like that, we should simply damage the full viewport.
,
Jan 19 2017
Issue 670509 has been merged into this issue.
,
Jan 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/efb8e7ef70d18b7380210e7244113653ab41cf42 commit efb8e7ef70d18b7380210e7244113653ab41cf42 Author: vmpstr <vmpstr@chromium.org> Date: Fri Jan 20 23:36:15 2017 cc: Ensure that large damage doesn't register as "frame has no damage" When we have accumulating damage from really large or really far rects we can't union them correctly. So instead, introduce a DamageAccumulator that detects this and an additional function ShouldDamageEverything that ensures that if we run into this situation, we just damage everything we can. R=danakj@chromium.org, enne@chromium.org BUG= 678432 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2632463005 Cr-Commit-Position: refs/heads/master@{#445208} [modify] https://crrev.com/efb8e7ef70d18b7380210e7244113653ab41cf42/cc/debug/debug_rect_history.cc [modify] https://crrev.com/efb8e7ef70d18b7380210e7244113653ab41cf42/cc/layers/render_surface_impl.cc [modify] https://crrev.com/efb8e7ef70d18b7380210e7244113653ab41cf42/cc/layers/render_surface_impl.h [modify] https://crrev.com/efb8e7ef70d18b7380210e7244113653ab41cf42/cc/trees/damage_tracker.cc [modify] https://crrev.com/efb8e7ef70d18b7380210e7244113653ab41cf42/cc/trees/damage_tracker.h [modify] https://crrev.com/efb8e7ef70d18b7380210e7244113653ab41cf42/cc/trees/damage_tracker_unittest.cc [modify] https://crrev.com/efb8e7ef70d18b7380210e7244113653ab41cf42/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/efb8e7ef70d18b7380210e7244113653ab41cf42/cc/trees/layer_tree_host_unittest_damage.cc [modify] https://crrev.com/efb8e7ef70d18b7380210e7244113653ab41cf42/cc/trees/layer_tree_host_unittest_video.cc
,
Jan 31 2017
Please verify.
,
Feb 9 2017
Due to more issues like this creeping up (see crbug.com/686873 ), I'd like to merge this to 57 if possible.
,
Feb 9 2017
Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions. Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 9 2017
Please merge your change to M57 branch 2987 before 5:00 PM PT, Friday 02/10 (sooner the better please) so we can take it in for next week beta release. Thank you.
,
Feb 9 2017
Changing to assign state due to pending merge to M57. It appears this will also resolve issue 686873 .
,
Feb 9 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4199618e79323f620735b60e833bdc77bca3c77c commit 4199618e79323f620735b60e833bdc77bca3c77c Author: Vladimir Levin <vmpstr@chromium.org> Date: Thu Feb 09 20:22:47 2017 cc: Ensure that large damage doesn't register as "frame has no damage" When we have accumulating damage from really large or really far rects we can't union them correctly. So instead, introduce a DamageAccumulator that detects this and an additional function ShouldDamageEverything that ensures that if we run into this situation, we just damage everything we can. R=danakj@chromium.org, enne@chromium.org BUG= 678432 , 686873 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2632463005 Cr-Commit-Position: refs/heads/master@{#445208} (cherry picked from commit efb8e7ef70d18b7380210e7244113653ab41cf42) Review-Url: https://codereview.chromium.org/2683113003 . Cr-Commit-Position: refs/branch-heads/2987@{#414} Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943} [modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/debug/debug_rect_history.cc [modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/layers/render_surface_impl.cc [modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/layers/render_surface_impl.h [modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/trees/damage_tracker.cc [modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/trees/damage_tracker.h [modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/trees/damage_tracker_unittest.cc [modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/trees/layer_tree_host_unittest_damage.cc [modify] https://crrev.com/4199618e79323f620735b60e833bdc77bca3c77c/cc/trees/layer_tree_host_unittest_video.cc
,
Feb 9 2017
,
Feb 9 2017
Issue 686873 has been merged into this issue.
,
Feb 15 2017
Tested the issue on Windows-7, Mac-10.12.2 and Linux Ubuntu-14.04 using 57.0.2987.54 as per the comment#0. Observed that the fix is working as expected. Attaching screen cast for reference . Hence,adding the verified labels. Thanks. |
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by nyerramilli@chromium.org
, Jan 5 2017