Web animations API gets stuck in "pending" state
Reported by
a...@scirra.com,
Nov 18 2016
|
|||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2922.0 Safari/537.36 Steps to reproduce the problem: View the attached demo, or view online at https://www.scirra.com/labs/bugs/animbug/ The demo creates lots of boxes with a fade-in animation using the Web Animations API. On a timer it regularly hides all the existing boxes and creates a new set. The box has logic so that if it's still fading in when it's hidden, it simply reverses the fade-in animation. Sometimes, sporadically, the reverse() call leaves the animation permanently in a "pending" state. The box appears at its normal (finished) state and gets left stuck on-screen, since the onfinish event never fires. Follow these steps to observe the issue: 1. Open the demo and watch it for a while. The issue is irregular but the demo stress-tests it as hard as possible to try and cause the problem. You may need to reload a few times, or leave it running for a while. 2. At some point, a set of the green boxes should get stuck not animating. 3. Press the "stop" button. 4. Observe the count of boxes in "pending" state. What is the expected behavior? Animations should always finish playing. There should be 0 boxes left in "pending" state after pressing stop. What went wrong? Animations get stuck in "pending" state and don't finish. There are some boxes left in "pending" state after pressing stop. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 56.0.2922.0 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 24.0 r0 The demo works correctly in Firefox, which is the only other browser that implements the Web Animations API currently. The problem can be reproduced with just one or two animations, but it's very rare like that. The only reason the demo creates many at a time is to try and reproduce the problem as quickly as possible.
,
Nov 21 2016
,
Nov 21 2016
Able to repro interop difference. This might be the same bug as issue 648114 .
,
Nov 21 2016
Able to reproduce the issue on win10 mac and Linux using chrome version 56.0.2922.1 and canary - There are some boxes left in "pending" state after pressing stop. This is working fine on firefox browser This is a non regression issue existing since M45 45.0.2454.101 to latest canary <M45 behavior : No animations played
,
Nov 23 2016
,
Jan 11 2017
Assigning to Alan (since he owns issue 648114 ) to investigate whether this can be downgraded to Quarterly.
,
Feb 17 2017
Has anyone discovered a work around to this issue?
,
Feb 18 2017
The workaround I use is: anywhere you call reverse(), set a timer for 50ms. If 50ms later the animation is still in a pending state, terminate it. You have to do this on every single call to reverse(), because every call has a small chance of getting stuck.
,
May 23 2017
Still reproduces in Canary 60.0.3108.0, although seems to be rarer now. I have to run the repro for longer before the issue starts happening.
,
Jul 13 2017
This is definitely a weird interaction between the main thread and the compositor related to the compositor trying to send start times to the main thread. Perhaps the compositor thread is getting overloaded invoking a race-condition. Unassigning self from this bug as I am temporarily transferring away from Chrome.
,
Nov 27 2017
Still reproduces in canary 64.0.3278.0. I accidentally found another weird quirk of this bug: when you press 'Stop' and there are boxes stuck in a pending state, switch to another tab, then come back to the test tab. All but one of the stuck animations then resume and complete, but for some reason one is left behind, so it remains on "1 in 'pending' state".
,
Dec 30 2017
It seems semi-fixed in 65.0.3308.0 canary. The boxes all pile up stuck in pending mode, but as soon as you stop it so there's some idle time, they all finish simultaneously. That doesn't seem like the ideal behavior though.
,
Dec 31
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 3
With 71.0.3578.98 it seems chrome is still not working correctly. On firefox, there are always 100-150 animated boxes with 0 pending state all the time. But on chrome, the animated boxes begin to accumulate and the number of boxes in pending state is always equal to the number of animated boxes. See attachment for screenshot. cc folks for more confirmation. |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by ligim...@chromium.org
, Nov 18 2016