A resolution was made for csswg-drafts/#4441.

[css-transitions-2] Start transitions on discrete animation types

• RESOLVED: if a discretely animatable property is listed in a transition it will. by default the all keyword will not transition

Discussion.

Clarifying slightly:

Up until this point, the spec has said the following (in section 3 "Starting of transitions"):

When comparing the before-change style and after-change style for a given property, the property values are transitionable if they have an animation type that is neither not animatable nor discrete.

Today's resolution made this change:

• we're removing the "...nor discrete" qualifier. So: now properties with animation-type "disrete" are considered to be transitionable
• they transition when their easing function gets past 50%, essentially (this falls implicitly out of the animation spec and how it interacts with transitions)
• discretely-transitionable properties are not included in transition-property: all. If you want to transition them, you have to explicitly list them by name in the transition-property list.

(There's a proposal to include another catch-all keyword for all such properties so that you could do something like transition-property: all, discrete, but we didn't resolve on that today.)

+CC :boris and :hiro -- this seems like it'll be needed for interop2023, if either of you have cycles to pick up this transitions spec change. (Looks like the Chrome equivalent was https://bugs.chromium.org/p/chromium/issues/detail?id=1399631 which landed recently.)

(See bug 1822203 for some interop2023-relevant WPT tests that currently depend on this change.)

It should be straight-forward, just removing this condition would work? I may be wrong since my memory about animation is quite stale.

(In reply to Daniel Holbert [:dholbert] from comment #2)

+CC :boris and :hiro -- this seems like it'll be needed for interop2023, if either of you have cycles to pick up this transitions spec change. (Looks like the Chrome equivalent was https://bugs.chromium.org/p/chromium/issues/detail?id=1399631 which landed recently.)

(See bug 1822203 for some interop2023-relevant WPT tests that currently depend on this change.)

Yes. I also noticed there are some wpt failures of motion path because of this bug.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)

It should be straight-forward, just removing this condition would work? I may be wrong since my memory about animation is quite stale.

I will try it once the wpt gets merged. I suspect we may have to do other changes but I can take a look at this after the web-platform tests are ready in our repo.

Waiting for wpt sync.

We need to make sure "all" doesn't transition discrete properties, but hopefully that's covered.

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

We need to make sure "all" doesn't transition discrete properties, but hopefully that's covered.

Right. We may have to update the logic here as well, to accept discrete animation type only for longhand properties in the list.

(putting Boris in Assigned field to reflect reality, since I think he's working on this now or in the near term. Thanks Boris! Feel free to unassign if I'm misunderstanding. :) )

This refactoring is needed because we cannot make decision to cancel the
transitions during the loop, before finishing the check of all transition
properties.

The next patch will start transitions on discrete animation types, only
if we specify the specific transition properties (i.e. longhand and shorthand
properties). We don't start transition on discrete animations if this
transition is from all property (i.e. transition-property: all).

The only difference is the usage of nsCSSProps::IsEnabled() for all
keyword when handling the cancellation of existing transitions.

However, this is a kind of preference check so it shouldn't break the
consistency.

Just try to make it easier to read the code.

So we don't have to go through transition-property twice.

We still disable the global preference, but only enable it for WPT.

So basically, we just drop the unexpected pass from the meta. The
only exception is css/css-transitions/CSSTransition-canceling.tentative.html.
We should use all in the test so we cancel the transition when using a
non-interpolatable property value.

For Gecko internal layout tests, there are a lot of change in
test_transitions_per_property.html:

1. Add a global array to represent the properties with discrete
   animation types, so we skip these properties in general.
2. Update the expectation when the test fall back to discrete.
3. Skip tests of Motion path because we have enough tests in WPT.

For Gecko internal animation tests, we use all keyword in
test_animation_observers_sync.html to make sure we still cancel the
transition with non-interpolated values.

We got timeout in

1. browser/components/customizableui/test/browser_947914_button_history.js
2. browser/components/places/tests/browser/browser_toolbar_library_open_recent.js
3. browser/modules/test/browser/browser_UsageTelemetry_interaction.js

I suspect these interaction tests expect there is no transition for
some cases. For example, browser_947914_button_history.js hangs when
calling await browserLoaded because it seems like the test doesn't click
the selected item. Not sure what happens exactly, so for now I just disable
the pref for them and we have to fix them later.

Note: as noted on https://github.com/web-platform-tests/wpt/issues/39871#issuecomment-1536898732, it seems the spec's relatively-simple "transition:all expands-to-all-non-discrete-properties" behavior is not necessarily web-compatible.

A Chromium engineer linked to one regression that they ran into there:, where it's problematic for "transition:all" to cause discrete transitions to play for a change from top:auto to top:50%: https://bugs.chromium.org/p/chromium/issues/detail?id=1439802

(They also mentioned "It may turn out that we can't ship this new discrete transition behavior at all, but I am still working on figuring that out.")

Independent of how code-review shakes out here, it'd be probably worth hold off on landing this for at least a week or so. A chromium engineer working on this feature (@josepharhar) is doing a bit of research with their implementation this week[1], which might result in an assessment that this behavior is "for sure unshippable" (at which point presumably there'd be a csswg discussion / spec update).

(That would be quite unfortunate after all the work you've put into implementing it and updating test-expectations etc. :-/ Sorry about that if that turns out to be the case. Though I suppose it's nice that the Chromium folks are discovering the possible webcompat breakage before we've landed rather than later in our release process.)

[1] https://github.com/web-platform-tests/wpt/issues/39871#issuecomment-1538653293

I will move part 1 to part 3 to a separate bug (Bug 1831981) because these three patches don't change the behavior and just improve the readability. So we can land them first.

Comment on attachment 9328636 [details]
Bug 1805727 - Part 1: Share code for expanding all keyword and shorthands when iterating transition-property list.

Revision D175533 was moved to bug 1831981. Setting attachment 9328636 [details] to obsolete.

Comment on attachment 9327607 [details]
Bug 1805727 - Part 2: Move the cancellation of transitions into a separate function.

Revision D174985 was moved to bug 1831981. Setting attachment 9327607 [details] to obsolete.

Comment on attachment 9328637 [details]
Bug 1805727 - Part 3: Make the creation of a transition be a separate function.

Revision D175534 was moved to bug 1831981. Setting attachment 9328637 [details] to obsolete.

(In reply to Daniel Holbert [:dholbert] from comment #17)

A Chromium engineer [...] also mentioned "It may turn out that we can't ship this new discrete transition behavior at all, but I am still working on figuring that out.")

Update: there's now a spec issue on putting this new behavior behind a new syntax, so that it can become opt-in instead of changing the default behavior. That's https://github.com/w3c/csswg-drafts/issues/8857

(Not sure what that means for all the interop2023-relevant WPTs that were changed to expect this behavior, but I suspect those should all be reverted to test the old currently-shipping-in-all-browsers behavior, and there'll be some new test to specifically test the new behavior.)

So we can reuse this bug to implement https://github.com/w3c/csswg-drafts/issues/8857#issuecomment-1581650809.

The spec has been updated (https://drafts.csswg.org/css-transitions-2/#transition-behavior-property).

Need to support this new CSS property, so we have the ability to start the CSS transitions for property or values that are animatable discretely:
<transition-behavior-value> = normal | allow-discrete

Add transition-behavior longhand property. This doesn't include layout
animation support.

Per spec, we put transition-behavior last in transition.

https://drafts.csswg.org/css-transitions-2/#transition-shorthand-property

Per https://github.com/web-platform-tests/wpt/issues/43574, we should
follow the shortest serialization principle for transition shorthand.

Comment on attachment 9377849 [details]
Bug 1805727 - Part 3: Follow shortest serialization principle for transition shorthand.

Revision D200410 was moved to bug 1878758. Setting attachment 9377849 [details] to obsolete.

Its name doesn't match the current spec because all is not a special case for
transition-behavior. (For more specifically, it uses the obsolete spec
definition.)

The implementation is straight-forward. We have to check
if transition-behavior is allow-discrete when trying to create a new
transition and when checking if we have to cancel a running transition.

Also, the test case is out-of-date, so I tweak it a little bit and add
more general test cases for transtiion-behavior.

When transition-behavior is allow-discrete, the animation values are
transitionable even if they are not interpoltable, given that the
animation type of the CSS property is by computed value.

https://hg.mozilla.org/mozilla-central/rev/8ffd5fe0ee69
https://hg.mozilla.org/mozilla-central/rev/ea25a67b45f8
https://hg.mozilla.org/mozilla-central/rev/6b9c12c81a43
https://hg.mozilla.org/mozilla-central/rev/9c80651bc341
https://hg.mozilla.org/mozilla-central/rev/6203d25d0748

Proposal to add tests into interop meta: https://github.com/web-platform-tests/interop/issues/639

https://hg.mozilla.org/mozilla-central/rev/0145f8600b88

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

Is this something we should add to the Fx125 relnotes?

Release Note Request (optional, but appreciated)
[Why is this notable]: This is a new feature defined in CSS Transitions Module Level 2. We support transition-behavior property so the users can determine whether we generate the CSS transitions for properties with the discrete animation type, or for properties whose animation values fall back to discrete animations (i.e. not interpolatable but discretely animatable).
[Affects Firefox for Android]: Yes. This affects all platforms.
[Suggested wording]: Support transition-behavior property on Nightly
[Links (documentation, blog post, etc)]: https://www.w3.org/TR/css-transitions-2/#transition-behavior-property

Note: This is enabled on Nightly only for now, and we would like to wait for at least 3 cycles.

Added to the Nightly relnotes, thanks.

Starting with Firefox 125, the transition-behavior CSS property is now supported in Nightly builds.

MDN docs changes can be tracked in the following GitHub issue: https://github.com/mdn/content/issues/32664