Intent to implement: Automatically removing replaced filling Web Animations

[Brian Birtles]

*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
) 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

Re: Intent to ship: Visual Viewport API on Android

[David Burns]

There are a number of wpt that fail only in firefox[1]. Are we planning on
fixing those tests with this work?

David

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1546387

On Thu, 9 May 2019 at 01:41, Botond Ballo  wrote:

> Hi everyone!
>
> I would like to ship the Visual Viewport API [1] on Android. The
> initial implementation [2] was done in Firefox 63 behind the pref
> "dom.visualviewport.enabled" (see "Intent to Implement" thread [3]).
> It has since seen bug fixes, polish, and expanded test coverage.
>
> I intend to ship it on Android only for now. The API is primarily
> useful in scenarios involving pinch-zooming, and we don't currently
> support pinch-zooming on desktop. I intend to enable it on desktop
> concurrently with support for pinch-zooming at a later date.
>
> Target release: Firefox 68 or 69, depending on when the patches are
> ready. If it doesn't make 68, I would like to get it into Fennec
> 68.1esr, as it's an important web compat feature.
>
> Tracking bug for shipping:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1512813
>
> Status in other implementation:
>   Blink: Shipping since Chrome 61 [4]
>   Safari: Available in Preview version [5]
>
> Web platform tests: The feature has good WPT coverage, with a mix of
> automatic and manual tests. We are now [6] passing almost all tests on
> Android; of the two remaining failures, one is a test harness
> limitation [7], and the other is pending resolution of a spec issue
> [8]. There are also a couple of tests which are not applicable to
> Android because they involve reflowing zoom which Android does not
> support.
>
> Any thoughts / feedback is appreciated!
>
> Thanks,
> Botond
>
> [1] https://github.com/WICG/visual-viewport/
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1357785
> [3]
> https://groups.google.com/d/topic/mozilla.dev.platform/gchNtWfv_bk/discussion
> [4] https://www.chromestatus.com/feature/5737866978131968
> [5] https://webkit.org/status/#feature-visual-viewport-api
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1477610
> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1547827
> [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1543485
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform