Closed Bug 1805727 Opened 2 years ago Closed 4 months ago

[css-transitions-2] Support transition-behavior property

Categories

(Core :: CSS Transitions and Animations, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
125 Branch
Tracking Status
relnote-firefox --- nightly+
firefox125 --- fixed

People

(Reporter: mozilla-apprentice, Assigned: boris)

References

(Depends on 1 open bug, Blocks 5 open bugs, )

Details

(Keywords: dev-doc-complete)

Attachments

(6 files, 9 obsolete files)

48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

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. :) )

Assignee: nobody → boris.chiou
Status: NEW → ASSIGNED

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).

Attachment #9323129 - Attachment description: Bug 1805727 - Let CSS Transitions start on discrete animation types (wip). → Bug 1805727 - Part 2: Let CSS Transitions start on discrete animation types.

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.

Attachment #9327607 - Attachment description: Bug 1805727 - Part 1: Move the cancellation for transitions which become non-transitionable. → Bug 1805727 - Part 2: Move the cancellation for transitions which become non-transitionable.

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.

Attachment #9323129 - Attachment description: Bug 1805727 - Part 2: Let CSS Transitions start on discrete animation types. → Bug 1805727 - Part 5: Let CSS Transitions start on discrete animation types.

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.

Attachment #9327607 - Attachment description: Bug 1805727 - Part 2: Move the cancellation for transitions which become non-transitionable. → Bug 1805727 - Part 2: Move the cancellation of transitions which become non-transitionable out of the loop.
Attachment #9328637 - Attachment description: Bug 1805727 - Part 3: Make the creation of a transition as a separate function. → Bug 1805727 - Part 3: Make the creation of a transition be a separate function.
Attachment #9328638 - Attachment description: Bug 1805727 - Part 4: Drop the potential redundant "for" loop when checking no longer used transition properties. → Bug 1805727 - Part 4: Avoid going through transition-property list again for cancellation.

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.

Blocks: 1830785
Attachment #9327607 - Attachment description: Bug 1805727 - Part 2: Move the cancellation of transitions which become non-transitionable out of the loop. → Bug 1805727 - Part 2: Move the cancellation of transitions into a separate function.
Blocks: 1830800
Blocks: 1831666

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.

See Also: → 1831981

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.

Attachment #9328636 - Attachment is obsolete: true
Depends on: 1831981
See Also: 1831981

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.

Attachment #9327607 - Attachment is obsolete: true

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.

Attachment #9328637 - Attachment is obsolete: true

(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.)

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

Summary: [css-transitions-2] Start transitions on discrete animation types → [css-transitions-2] Support transition-behavior property
Type: defect → enhancement
Attachment #9328638 - Attachment is obsolete: true
Attachment #9323129 - Attachment is obsolete: true
Attachment #9328639 - Attachment is obsolete: true
Attachment #9328640 - Attachment is obsolete: true
Attachment #9329587 - Attachment is obsolete: true
Blocks: 1855008
No longer blocks: interop-2024

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

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

Attachment #9377849 - Attachment description: Bug 1805727 - Part 3: Support shortest serialization principle for transition shorthand. → Bug 1805727 - Part 3: Follow shortest serialization principle for transition shorthand.
Depends on: 1878448
Depends on: 1878758

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.

Attachment #9377849 - Attachment is obsolete: true

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.

Blocks: 1881836
Pushed by bchiou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8ffd5fe0ee69
Part 1: Support transition-behavior longhand in style. r=emilio
https://hg.mozilla.org/integration/autoland/rev/ea25a67b45f8
Part 2: Add transition-behavior to transition shorthand in style. r=emilio
https://hg.mozilla.org/integration/autoland/rev/6b9c12c81a43
Part 3: Rename all-with-discrete.tentative.html. r=emilio
https://hg.mozilla.org/integration/autoland/rev/9c80651bc341
Part 4: Implement transition-behavior for properties with discrete animation type. r=emilio
https://hg.mozilla.org/integration/autoland/rev/6203d25d0748
Part 5: Support transition-behavior when animation values fall back to discrete. r=emilio
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/44761 for changes under testing/web-platform/tests
Duplicate of this bug: 1855008
Upstream PR merged by moz-wptsync-bot

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

Pushed by bchiou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0145f8600b88
Fix the typo of the test name, transition-behavior.html. r=layout-reviewers,tnikkel
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/44772 for changes under testing/web-platform/tests

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)

Upstream PR merged by moz-wptsync-bot

Is this something we should add to the Fx125 relnotes?

Flags: needinfo?(boris.chiou)

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.

Depends on: 1882408

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

Blocks: 1901645
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: