*Summary:* Using the Web Animations API it is possible to unwittingly trigger indefinitely-filling animations in a manner that effectively leaks memory. Recently-specified automatic removal behavior requires user agents to remove animations that are fully overlapped by other filling animations and then dispatch an event so that the author can explicitly restore such animations (thereby acknowledging the performance implications) or apply their effect by other means.
*Bug:* https://bugzilla.mozilla.org/show_bug.cgi?id=1253476 *Link to standard:* https://drafts.csswg.org/web-animations-1/#replacing-animations *Platform coverage:* All platforms *Estimated or target release:* Firefox 69 *Preference behind which this will be implemented:* dom.animations-api.autoremove.enabled (I plan to turn this on by default in Nightly initially) *Is this feature enabled by default in sandboxed iframes?* Yes *DevTools bug:* Automatically removed animations will be hidden from the Animation inspector. I don't think further indications are required at this stage. *Do other browser engines implement this?* Not yet but it has been discussed at length with representatives from Apple, Google, and Microsoft who have indicated their interest in implementing this feature--although not likely until this summer. *web-platform-tests:* The patches in the above-mentioned bug include extensive web-platform-tests *Is this feature restricted to secure contexts?* No, since the Web Animations API as a whole is not restricted to secure contexts and this modifies behavior already available in insecure contexts. *Web compatibility risk:* The Web compatibility risk of this change is minimized by the fact that both the getAnimations() method and additive animations are not yet shipping in any browser. Furthermore, the automatic removal does not apply to CSS animations or CSS transitions. As a result, the only circumstances where this change is observable to Web content is if the author triggers multiple overlapping filling animations (in the sense of covering the same properties) using the Web Animations API and then calls cancel() on the topmost animation and expects the now-exposed underlying animation(s) to still take effect. Furthermore the only observable difference (beyond the additional event and IDL members) is in computed style--the timing properties and behavior of the removed animations are unaffected. That said, cancel() is used surprisingly widely (~3% of pageloads <https://www.chromestatus.com/metrics/feature/timeline/popularity/699>) but the pattern of overlapping animations then peeling back just the top one is expected to be rare. For example, none of the tests in our existing test suite are affected by this change. Turning this behavior on by default on Nightly will give us some indication of Web compatibility risk, but we may need to examine it more closely before shipping. Please let me know if you have questions or concerns. Best regards, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
