95950 2012-09-06 01:36:16 -0700 Animation state machine causes disappearing layers 2012-09-19 12:51:39 -0700 1 1 1 Unclassified WebKit Layout and Rendering 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 1 shawnsingh shawnsingh dino enne simon.fraser vollick oldest_to_newest 713025 0 shawnsingh 2012-09-06 01:36:16 -0700 This reproduces on both webkit nightly and chromium. To reproduce: 1. go to maps.google.com 2. enable MapsGL 3. make sure you are signed in (I could only reproduce this on my gmail account, not my google account) 4. reload maps.google.com with mapsGL enabled and being signed in --> this is needed to reliably reproduce the problem 5. click on "my places" Expected result: you should see a menu bar on the left-side area, with 4 buttons - "All, Maps, Starred, More" Actual result: the bar does not appear at first. If you resize the window to become small enough, it finally causes something to recompute so that it becomes visible. example of expected and buggy screenshots can be found at http://code.google.com/p/chromium/issues/detail?id=138213 More debugging details: The bug occurs because the menu bar buttons have a -webkit-transition animation on it to animate all properties. In particular, the visibility property has a beginning style as "not visible", and a target style of "visible". The animation seems to get stuck in the "AnimationStateStartWaitResponse" state, nothing seems to trigger the notification that would let the animations proceed. 713032 1 162451 shawnsingh 2012-09-06 01:52:33 -0700 Created attachment 162451 Hack that fixes the problem, just to illustrate what's going wrong I'm attaching a patch that fixes the problem, but it's clearly a bad hack, and not the correct solution. I think the real problem is either a missing notifyAnimationStarted() somewhere, or some bug in the state machine itself. I'm not clear where to begin looking for either of these possibilities. When are notifyAnimationStarted() events expected to occur? What is the relationship between different CSS properties when it comes to being "synchronized" to an accelerated animation? The comment in AnimationControllerPrivate::addToAnimationsWaitingForStartTimeResponse ---> is this comment accurate? the function does still add accelerated animations to the list, even though the comment says it does not. And what is the relationship between all these animations, how do they know they should be synchronized to the same notification event? It looks like the animations get stuck immediately after the animated dom elements are first initialized... but I'm not 100% sure about that yet. Suggestions where to continue looking would be appreciated! 713035 2 shawnsingh 2012-09-06 01:54:48 -0700 To clarify, the hack is essentially forcing non-accelerated animations to continue without waiting for a notification. This fixes the problem, but I'm assuming it's not a real correct fix. 713355 3 simon.fraser 2012-09-06 09:14:43 -0700 A reduced testcase would be helpful. 714877 4 shawnsingh 2012-09-07 12:59:43 -0700 (In reply to comment #3) > A reduced testcase would be helpful. Making a reduced case has proven to be very elusive =) One question that would help me make the reduced test case - What is a valid situation where composited layers are created, but not actually added to the GraphicsLayer tree? That seems to be what is happening on the google maps page. 714912 5 simon.fraser 2012-09-07 13:37:18 -0700 That might happen if there are visibility:hidden layers, possibly. 722327 6 shawnsingh 2012-09-17 15:41:24 -0700 I wasn't able to create a reduced test case. In the mean-time, i think pages that had this bug have worked around it, so it no longer reproduces on webkit nightly either. So I think this is a WONTFIX until we have a more solid repro. tl;dr - Here's where I left off, for archival purposes: The root of the issue was that there are (hard-to-reproduce) cases where accelerated animations do not actually start when startAnimation() is called and returns true. Because of this, all animations waiting to sync get stuck until the accelerated animation finally starts. However, I don't think its a bug with accelerated compositor code - this seemed to occur particularly for a composited layer that was not part of the GraphicsLayer tree. So it did not have the correct delegate/client callbacks to notifyAnimationStarted(). It seems that WebCore is doing something inconsistent to cause this. Either WebCore needs to never have any orphan composited layers, or the animation system may need to have additional logic that prevents animations from trying to sync with an accelerated animation that might hang. 722381 7 simon.fraser 2012-09-17 17:34:09 -0700 We've certainly had problem with animations on detached layers before (layers for visibility:hidden). 723726 8 simon.fraser 2012-09-19 12:51:39 -0700 This might be related: https://bugs.webkit.org/show_bug.cgi?id=26770 162451 2012-09-06 01:52:33 -0700 2012-09-06 09:13:51 -0700 Hack that fixes the problem, just to illustrate what's going wrong hacked-fix-for-stuck-animation.patch text/plain 1381 shawnsingh ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL3BhZ2UvYW5pbWF0aW9uL0FuaW1hdGlvbkJhc2Uu Y3BwIGIvU291cmNlL1dlYkNvcmUvcGFnZS9hbmltYXRpb24vQW5pbWF0aW9uQmFzZS5jcHAKaW5k ZXggMzNkNjMyNi4uZTRmYzM4ZCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcGFnZS9hbmlt YXRpb24vQW5pbWF0aW9uQmFzZS5jcHAKKysrIGIvU291cmNlL1dlYkNvcmUvcGFnZS9hbmltYXRp b24vQW5pbWF0aW9uQmFzZS5jcHAKQEAgLTIyMiw4ICsyMjIsMTggQEAgdm9pZCBBbmltYXRpb25C YXNlOjp1cGRhdGVTdGF0ZU1hY2hpbmUoQW5pbVN0YXRlSW5wdXQgaW5wdXQsIGRvdWJsZSBwYXJh bSkKICAgICAgICAgICAgICAgICAgICAgICAgIHRpbWVPZmZzZXQgPSAtbV9hbmltYXRpb24tPmRl bGF5KCk7CiAgICAgICAgICAgICAgICAgICAgIGJvb2wgc3RhcnRlZCA9IHN0YXJ0QW5pbWF0aW9u KHRpbWVPZmZzZXQpOwogCi0gICAgICAgICAgICAgICAgICAgIG1fY29tcEFuaW0tPmFuaW1hdGlv bkNvbnRyb2xsZXIoKS0+YWRkVG9BbmltYXRpb25zV2FpdGluZ0ZvclN0YXJ0VGltZVJlc3BvbnNl KHRoaXMsIHN0YXJ0ZWQpOworCiAgICAgICAgICAgICAgICAgICAgIG1faXNBY2NlbGVyYXRlZCA9 IHN0YXJ0ZWQ7CisgICAgICAgICAgICAgICAgICAgIGlmIChtX2lzQWNjZWxlcmF0ZWQpIHsKKyAg ICAgICAgICAgICAgICAgICAgICAgIG1fY29tcEFuaW0tPmFuaW1hdGlvbkNvbnRyb2xsZXIoKS0+ YWRkVG9BbmltYXRpb25zV2FpdGluZ0ZvclN0YXJ0VGltZVJlc3BvbnNlKHRoaXMsIHN0YXJ0ZWQp OworICAgICAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgICAgIGVsc2UgeworICAg ICAgICAgICAgICAgICAgICAgICAgbV9hbmltU3RhdGUgPSBBbmltYXRpb25TdGF0ZVN0YXJ0V2Fp dFJlc3BvbnNlOworICAgICAgICAgICAgICAgICAgICAgICAgdXBkYXRlU3RhdGVNYWNoaW5lKEFu aW1hdGlvblN0YXRlSW5wdXRTdGFydFRpbWVTZXQsIGJlZ2luQW5pbWF0aW9uVXBkYXRlVGltZSgp KTsKKyAgICAgICAgICAgICAgICAgICAgfQorICAgICAgICAgICAgICAgICAgICAKKyAgICAgICAg ICAgICAgICAgICAgLy9tX2NvbXBBbmltLT5hbmltYXRpb25Db250cm9sbGVyKCktPmFkZFRvQW5p bWF0aW9uc1dhaXRpbmdGb3JTdGFydFRpbWVSZXNwb25zZSh0aGlzLCBzdGFydGVkKTsKKyAgICAg ICAgICAgICAgICAgICAgLy9tX2lzQWNjZWxlcmF0ZWQgPSBzdGFydGVkOwogICAgICAgICAgICAg ICAgIH0KICAgICAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICAgICAgLy8gV2UncmUgd2Fp dGluZyBmb3IgdGhlIHN0eWxlIHRvIGJlIGF2YWlsYWJsZSBhbmQgd2UgZ290IGEgcGF1c2UuIFBh dXNlIGFuZCB3YWl0Cg==