| Summary: | [Web Animations] Crash under AnimationTimeline::cancelOrRemoveDeclarativeAnimation() | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Antoine Quint <graouts> | ||||
| Component: | Animations | Assignee: | Antoine Quint <graouts> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | dexxenon, dino, eric.carlson, webkit-bug-importer | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | Other | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=188253 | ||||||
| Attachments: |
|
||||||
|
Description
Antoine Quint
2018-08-13 10:09:30 PDT
We also have a crash in this function in webkit.org/b/188253. I also came across webkit.org/b/188518 trying to figure out why the site was crashing. To reproduce this crash, we need to comment out the ASSERT() from that other bug. In this case we would crash because we blindly assumed an animation that was found in the previous style must be in the list of running animations but in fact it could have been removed already due to the element being removed from the DOM. So when we iterate over names of animations that were found in the previous style but not in the new style, we must make a null check to ensure that there is an animation to remove. Adding an ASSERT() in AnimationTimeline::cancelOrRemoveDeclarativeAnimation() will also clarify the contract here. *** Bug 188253 has been marked as a duplicate of this bug. *** Created attachment 347072 [details]
Patch
Committed r234848: <https://trac.webkit.org/changeset/234848> |