Closed Bug 1459536 Opened 6 years ago Closed 4 years ago

Record which fields of CSS animations / transitions have been overridden by script and ignore changes from style

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla75
Tracking Status
firefox61 --- wontfix
firefox75 --- fixed

People

(Reporter: birtles, Assigned: birtles)

References

Details

Attachments

(5 files, 1 obsolete file)

After bug 1456394 lands, there will no longer be any *ReadOnly interfaces. So, what should happen if script modifies the properties attached to a CSSAnimation / CSSTransition?

This will ultimately need to be specced in css-animations-2 / css-transitions-2 but having discussed this with Apple and Google we agree that if you override a property from script, the script-set value should prevail. In future, we may add API to reset/detect this case but for now it doesn't appear to be necessary.

In this bug we should implement that behavior. Until we ship getAnimations() this behavior won't be shipped, however, so this doesn't need to be blocked on the spec work (although hopefully spec shouldn't be too far behind, and ideally ahead).
Priority: -- → P3
Blocks: 1460554

Given that CSS transitions properties are snapshotted when the transition is created (i.e. changing transition-duration doesn't affect running transitions), I think that once bug 1292001 is done, the only thing left to do for transitions will be to add tests that changing the timing properties via the API actually does take effect.

As a result, this bug is mostly concerned with CSS Animations. Boris, if you are interested, feel free to take this bug. I think it mostly involves writing a bunch of WPT for each of the different timing properties / keyframes. Actually recording which properties changed is hopefully not too difficult? I think it might just involve sticking a bitfield on CSSAnimation that tracks which of the following have been overridden:

  • The effect as a whole (in which case changes to any of the following should be ignored)
    • The effect's keyframes
    • Each of the effect's timing properties
  • The animation's play state

The last point might be a separate bug. The current thinking is we should drop the special playback behavior defined in the spec: https://drafts.csswg.org/css-animations-2/#animation-play-state and simply say that if the author ever calls play(), pause(), reverse() etc. or sets the startTime etc. then the animation ignores changes to animation-play-state from that point on.

I don't think we'd need to track if the target/pseudo is changed, for example, since that's not possible to change via CSS. Likewise, technically we don't need to track if endDelay is changed, necessarily.

I'm happy to help with any spec changes for that.

Assignee: nobody → boris.chiou

Hi Boris, I think we need to get this landed within the next 2~3 days before the soft code freeze.

I hope you don't mind but I wrote a patch just to outline what I think we need to do. It only covers setKeyframes() but hopefully it explains the approach I have in mind.

If you like I can take this bug and fill out the rest of the patches? If you are already working on this though, that's fine. Maybe this patch will be of some use.

Flags: needinfo?(boris.chiou)

Sorry I haven't started to work on this yet. Please feel free to take this and finish your patch. :)

Flags: needinfo?(boris.chiou)
Assignee: boris.chiou → nobody
Comment on attachment 9130065 [details] [diff] [review]
WIP patch covering just setKeyframes

Review of attachment 9130065 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/style/nsAnimationManager.h
@@ +278,5 @@
>  } /* namespace dom */
>  
> +// A subclass of KeyframeEffect that reports when specific properties have been
> +// overridden via the Web Animations API.
> +class CSSAnimationKeyframeEffect : public dom::KeyframeEffect {

So, unfortunately, we still need something like CSSTransitionKeyframeEffect for transition, though we just drop ElementPropertyTransition.

I'm thinking is it possible to add a type flag in Keyframe, so we can just check this flag, instead of doing this by polymophism.
Assignee: nobody → brian
Status: NEW → ASSIGNED

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

+// A subclass of KeyframeEffect that reports when specific properties have been
+// overridden via the Web Animations API.
+class CSSAnimationKeyframeEffect : public dom::KeyframeEffect {

So, unfortunately, we still need something like CSSTransitionKeyframeEffect
for transition, though we just drop ElementPropertyTransition.

I don't think we need it for CSS transitions, only CSS animations. For CSS transitions, you can't update the running transition by changing the CSS since the values are snapshotted at the point when the transition is generated.

I'm thinking is it possible to add a type flag in Keyframe, so we can just
check this flag, instead of doing this by polymophism.

Since we only need it for CSS animations, I'm inclined to use the subclass approach in order to keep KeyframeEffect simple. I agree that if we needed this for both CSS transitions and CSS animations it would be worth adding to KeyframeEffect however.

(In reply to Brian Birtles (:birtles) from comment #5)

I don't think we need it for CSS transitions, only CSS animations. For CSS transitions, you can't update the running transition by changing the CSS since the values are snapshotted at the point when the transition is generated.

Oh right. This is for setKeyframes(), so don't need to do this for CSS transition. :)

We will use this in the next patch to test the result after calling setKeyframes.

Attachment #9130065 - Attachment is obsolete: true
Pushed by bbirtles.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c206b97b7447
Extract common keyframe comparison test methods; r=boris
https://hg.mozilla.org/integration/autoland/rev/7c8d563e57ea
Ignore subsequent changes to @keyframes after calling setKeyframes; r=boris
https://hg.mozilla.org/integration/autoland/rev/d6f2c615730f
Allow CSS animation timing properties to be overridden using the Web Animations API; r=boris
https://hg.mozilla.org/integration/autoland/rev/4c24b62d2686
Allow CSS animation properties to be overridden by replacing the effect; r=boris
https://hg.mozilla.org/integration/autoland/rev/02295b7142ac
Replace CSSAnimation interaction with animation-play-state with a simpler "once overridden always overridden" approach; r=boris
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/22077 for changes under testing/web-platform/tests
No longer blocks: 1460554
Upstream PR merged by stephenmcgruer
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: