1619821 - Turn on dom.animations-api.getAnimations.enabled in release channels

Status: RESOLVED FIXED

(Core :: DOM: Animation, task, P3)

Description

[Brian Birtles (:birtles, Feb 26~ parental leave)]

I think that after bug 1619516 is fixed and I get a few more spec edits in we should be ready to turn this on by default.

Boris, does bug 1615083 need to block this?

Comment 1

[Boris Chiou [:boris]]

It seems element.getAnimations() checks its generated content. So if there is an animation targeting to a pseudo-element that doesn't have the generated content, element.getAnimations() may not add this animation in the list.

Bug 1615083 happens because we don't have generated content, so we cannot update its style. So I think both getAnimations() and Bug 1615083 has the same issue. In other words, unfortunately, bug 1615083 may block this. (i.e. Once we fix bug 1615083, getAnimations() should also work well.)

Comment 2

[Boris Chiou [:boris]]

(In reply to Boris Chiou [:boris] from comment #1)

It seems element.getAnimations() checks its generated content. So if there is an animation targeting to a pseudo-element that doesn't have the generated content, element.getAnimations() may not add this animation in the list.

Perhaps only document.getAnimations() has this issue because there is no way to access the non-generated content by JS, right?
Actually I'm not sure if we have to bind the animation to the element which doesn't have generated content.

Comment 3

[Boris Chiou [:boris]]

OK. I just write a test (https://jsfiddle.net/borischiou/wgsbpujr/):

target::before {
  margin-left: 10px;
}

<div id='target'></div>

const d = document.getElementById('target');

const effect = new KeyframeEffect(null, {opacity:['0.5', '1']}, 10000);
const anim = new Animation(effect, document.timeline);
anim.play();
effect.target = d;
effect.pseudoElement = '::before';

console.log(d.getAnimations({subtree: true}));
console.log(document.getAnimations());

I got one animation from both.

Comment 4

[Boris Chiou [:boris]]

Sorry, it seems document.getAnimations() and element.getAnimations() work well by my test. So comment 1 and comment 2 are not the issue. Perhaps bug 1615083 shouldn't block this I think.

Comment 5

[Julien Cristau [:jcristau] (back April 22)]

Can this wait until next week so it rides to 76? We're trying to avoid pref changes in the last few days of a nightly cycle.

Comment 6

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(In reply to Julien Cristau [:jcristau] from comment #5)

Can this wait until next week so it rides to 76? We're trying to avoid pref changes in the last few days of a nightly cycle.

I'm afraid we're targeting 75 for this in order to synchronize with Apple and Google's release plans.

Comment 7

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Intent to ship: https://groups.google.com/forum/#!topic/mozilla.dev.platform/gie9ExD2-mU

Comment 8

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Bug 1619821 - Turn on dom.animations-api.getAnimations.enabled unconditionally; r?smaug

This also removes the comment about CSSPseudoElement since that is now covered by a
separate pref: dom.css_pseudo_element.enabled.

Comment 9

[Brian Birtles (:birtles, Feb 26~ parental leave)]

I'm pretty sure Safari is shipping CSSTransition and CSSAnimation to non secure contexts but let me check...

Comment 10

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Confirmed that Safari Tech Preview 102 exposes these in non-secure contexts.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4a0d1e903112
Turn on dom.animations-api.getAnimations.enabled unconditionally; r=smaug

Comment 12

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/4a0d1e903112

Comment 13

[Chris Mills [:cmills]]

Documentation complete for this bug; see:

• https://github.com/mdn/sprints/issues/2933#issuecomment-604386088
• https://github.com/mdn/sprints/issues/2933#issuecomment-610839764

For details of what changes were made.