1261651 - Various animation inspector tests are going to permafail when Gecko 48 merges to Aurora (TypeError: el.animate is not a function at @http://example.com/browser/devtools/client/animationinspector/test/doc_simple_animation.html:120:5)

Status: RESOLVED FIXED

(DevTools :: Inspector: Animations, defect, P1)

Description

[Ryan VanderMeulen [:RyanVM]]

[Tracking Requested - why for this release]: Devtools permafail when Gecko 48 merges to Aurora in two weeks.

https://treeherder.mozilla.org/logviewer.html#?job_id=18975270&repo=try

TEST-UNEXPECTED-FAIL | devtools/client/animationinspector/test/browser_animation_click_selects_animation.js | uncaught exception - TypeError: el.animate is not a function at @http://example.com/browser/devtools/client/animationinspector/test/doc_simple_animation.html:120:5

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Patrick, maybe you can take a look? We're a bit short on time here given where we are in the release cycle :)

Comment 2

[Patrick Brosset <:pbro>]

el.animate is the main piece of the WebAnimations API that is being worked on at the moment. It almost shipped in FF47, but was pushed back to FF48. Which means that for the time being it is being disabled on purpose after nightly. So it seems expected that these tests will fail when merged in Aurora. Most probably, the fix to turn the feature back on on other non-nightly releases hasn't been done yet.
See bug 1253507.
Brian Birtles would know a lot more than me on this, but he's away until April 10 and not accepting NI?
NI? Boris who reviewed the patch, so he can confirm my understanding.

Comment 3

[Boris Zbarsky [:bzbarsky]]

The feature is not enabled on non-nightly, correct.

So the tests need to either be disabled on non-nightly (with a bug filed to reenable them once the feature is enabled) or enable the feature for the duration of the tests.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

I'm actually in the process of adding nightly_build to mozinfo, so the former should be an option in the near-future (with a fail-if condition so the tests UNEXPECTED-PASS when the feature is ready to ride the trains), but in general I think the latter (preffing it on in the test) would be preferable.

Comment 5

[Patrick Brosset <:pbro>]

Triaging as P1. I'll take a look at this bug in the coming days, making sure the tests set the right pref before starting.

Comment 6

[Patrick Brosset <:pbro>]

Attachment: MozReview Request: Bug 1261651 - Avoid using element.animate() in tests - Use Animation constructor isntead; r=miker

Review commit: https://reviewboard.mozilla.org/r/44963/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/44963/

Comment 7

[Patrick Brosset <:pbro>]

I ended up taking a third approach: using KeyframeEffect and Animation constructors to create animations rather than element.animate.

Comment 8

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Comment on attachment 8738949 [details]
MozReview Request: Bug 1261651 - Avoid using element.animate() in tests - Use Animation constructor isntead; r=miker

https://reviewboard.mozilla.org/r/44963/#review41515

Comment 9

[Patrick Brosset <:pbro>]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=552d0dc5504d&group_state=expanded

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/3706a7a1c2ff

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3706a7a1c2ff