Various animation inspector tests are going to permafail when Gecko 48 merges to Aurora (Type
Error: el .animate is not a function at @http://example .com/browser/devtools/client/animationinspector/test/doc) _simple _animation .html:120:5
RESOLVED FIXED in Firefox 47
|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
MozReview Request: Bug 1261651 - Avoid using element.animate() in tests - Use Animation constructor isntead; r=miker
58 bytes, text/x-review-board-request
|Details | Review|
[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
Patrick, maybe you can take a look? We're a bit short on time here given where we are in the release cycle :)
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.
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.
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.
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.
Assignee: nobody → pbrosset
Status: NEW → ASSIGNED
Priority: -- → P1
Created attachment 8738949 [details] 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/
Attachment #8738949 - Flags: review?(mratcliffe)
I ended up taking a third approach: using KeyframeEffect and Animation constructors to create animations rather than element.animate.
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
Attachment #8738949 - Flags: review?(mratcliffe) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox48: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
status-firefox47: unaffected → fixed
tracking-firefox47: --- → +
You need to log in before you can comment on or make changes to this bug.