1421502 - Work with animations firefox developer tools not working

Status: RESOLVED WONTFIX

(Developer Documentation Graveyard :: Developer Tools, enhancement)

Description

[charlesgum]

What did you do?
================
1. Followed the instructions in the work with animations tutorial
2. Updated to firefox 58.0b3
3. Tried another web animation example from a web animation api page

What happened?
==============
The animation tool says there is no animation present for the element that is selected and when clicking the firefox logo no animation occurs.

What should have happened?
==========================
The logo should animate and the tool should show the animation

Is there anything else we should know?
======================================

Comment 1

[John Whitlock [:jwhitlock]]

What is the URL of the animations tutorial?

Comment 2

[charlesgum]

Here is the url for the animations docs/tutorial
https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector/How_to/Work_with_animations

Comment 3

[John Whitlock [:jwhitlock]]

The page loads the example in an iframe:

https://mdn.mozillademos.org/en-US/docs/Tools/Page_Inspector/How_to/Work_with_animations/Animation_inspector_example:_Web_Animations_API$samples/firefox-logo-animation?revision=1320157

I can confirm there is an error in Firefox Developer Edition 58.0b5, 64-bit, on OSX. The animiation JS has the error "ReferenceError: KeyframeEffect is not defined.".

However, it appears to work on https://codepen.io/rachelnabors/pen/eJyWzm?editors=0010, even though KeyframeEffect also give a reference error.

If I load about:config, dom.animations-api.core.enabled is false. If I change it to True, both the mozillademos.org and the codepen animations work.

Was dom.animations-api.core.enabled turned off in FF Developer Edition?

Comment 4

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

KeyframeEffect is only enabled by default on Nightly builds. The demo in the wiki page needs to use Element.animate instead.

Comment 5

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

dom.animations-api.core.enabled has never been enabled in beta/release channels and now that Developer Edition is based on the beta channel it will also not be enabled there.

We are working on releasing more of the API bit by bit over the coming months but it will still be probably at least 6 months until KeyframeEffect is shipped to the release channel.

Comment 6

[John Whitlock [:jwhitlock]]

The page documents the KeyframeEffect, so the sample should continue using it.

I've updated the reference page to note "The Web Animations API is only enabled by default in Firefox Nightly builds. It was enabled in Developer Edition until 58, when it is no longer enabled by default."

Comment 7

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

No that's not right. Part of the Web Animations API has been enabled in release builds since Firefox 48. The part that demo uses has never been enabled in any release channel and was only available in Developer Edition until we dropped the Aurora channel.

Are we looking at the same page? The "Work with animations" doesn't document KeyframeEffect. It may document keyframe effects but they can be used (and are used) without shipping the KeyframeEffect constructor. Under the hood, all CSS animations, CSS transitions and Web animations use KeyframeEffect (or KeyframeEffectReadOnly) despite the fact we don't ship that constructor.

Comment 8

[John Whitlock [:jwhitlock]]

Sorry to be unclear. The reference page, with the new compatibility statement is:

https://developer.mozilla.org/en-US/docs/Web/API/KeyframeEffect

Element.animate is used extensively on the "Using the Web Animations API" page:

https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API/Using_the_Web_Animations_API

The page for the working with Animation inspector makes use of the KeyframeEffect, and uses videos to show what it looks like for people not using Firefox Nightly:

https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector/How_to/Work_with_animations

The page will need a significant rewrite to avoid using KeyframeEffect.

The bug was originally filed against "Mozilla Developer Network: Wiki Pages", which covers issues with the editing and rendering of wiki pages. I appreciate your clarification that this was available in FF Dev Edition, but isn't anymore. I believe the new home for the bug is "Developer Documentation: Developer Tools", where the writers can decide the priority of re-writing the page for the new Dev Edition situation.

Comment 9

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

(In reply to John Whitlock [:jwhitlock] from comment #8)
> Sorry to be unclear. The reference page, with the new compatibility
> statement is:
> 
> https://developer.mozilla.org/en-US/docs/Web/API/KeyframeEffect

Ok that makes sense. For what it's worth, after discussions with Google we decided not to list features that are not enabled in release channels in the compatibility table. So we should simply remove those rows altogether.

> Element.animate is used extensively on the "Using the Web Animations API"
> page:
> 
> https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API/
> Using_the_Web_Animations_API
> 
> The page for the working with Animation inspector makes use of the
> KeyframeEffect, and uses videos to show what it looks like for people not
> using Firefox Nightly:
> 
> https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector/How_to/
> Work_with_animations
> 
> The page will need a significant rewrite to avoid using KeyframeEffect.

I think it's just that one demo, right?

I'm happy to rewrite it using Element.animate. It's trivial. In fact, here it is: https://codepen.io/birtles/pen/YEREMq

If we do that I don't think we need to touch the videos since they don't show the code at all and the visual result is the same.

> The bug was originally filed against "Mozilla Developer Network: Wiki
> Pages", which covers issues with the editing and rendering of wiki pages. I
> appreciate your clarification that this was available in FF Dev Edition, but
> isn't anymore. I believe the new home for the bug is "Developer
> Documentation: Developer Tools", where the writers can decide the priority
> of re-writing the page for the new Dev Edition situation.

Sure, I was just restoring the original component since I assumed it was set by the link on MDN for reporting incorrect content. I guess not though.

Comment 10

[John Whitlock [:jwhitlock]]

birtles, I think we're on the same page. Thank you for your quick response on the Developer Edition situation, and the background on the agreement w/ Google. This will give the documentation team the info needed to decide the next action, and what the compatibility table should display.

charlesgum, thanks again for the bug - it is generating quite the discussion!

Comment 11

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

Great, thanks John!

Comment 12

[charlesgum]

You're welcome, John! Thanks, everyone. I really appreciate all the good work you all do! This has been an eye opening learning experience for me.

Comment 13

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.