[webkit-changes] [WebKit/WebKit] 1b793d: [web-animations] changing writing-mode or directio...

Antoine Quint noreply at github.com
Mon Nov 14 12:32:28 PST 2022


  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1b793da552f71613cc9d8b9b68ffe280890d2428
      https://github.com/WebKit/WebKit/commit/1b793da552f71613cc9d8b9b68ffe280890d2428
  Author: Antoine Quint <graouts at apple.com>
  Date:   2022-11-14 (Mon, 14 Nov 2022)

  Changed paths:
    M LayoutTests/imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-replacement-expected.txt
    M Source/WebCore/animation/KeyframeEffect.cpp
    M Source/WebCore/animation/KeyframeEffect.h
    M Source/WebCore/animation/KeyframeEffectStack.cpp
    M Source/WebCore/rendering/style/KeyframeList.cpp
    M Source/WebCore/rendering/style/KeyframeList.h
    M Source/WebCore/style/StyleResolver.cpp

  Log Message:
  -----------
  [web-animations] changing writing-mode or direction on an element that has an animation targeting a logical property should ensure animation resolution is scheduled
https://bugs.webkit.org/show_bug.cgi?id=247895

Reviewed by Antti Koivisto.

When an effect in an effect stack is finished and is entirely superseded by another animation targeting the same property,
it can be removed. The procedure to remove replaced animations [0] runs as part of the procedure to update animations and
send events, which in our code happens as a result of page rendering being updated.

In the case where an effect targets a logical property, the *resolved* property it targets can change if the "writing-mode"
or "direction" properties change. And if the resolved target property changes, then the replaced state of the associated
animation may change as well. As such, we must make sure to schedule an animation update when the resolved target property
changes.

To do this, we now track whether a KeyframeValue targets a property that was resolved from a logical property and set that
boolean flag in Style::Resolver::styleForKeyframe(), which populates the generated KeyframeList for both script-originated
animations and CSS Animations. CSS Transitions aren't a concern here since they cannot change resolved property in-flight,
instead being canceled altogether if "writing-mode" or "direction" changes.

Then in KeyframeEffectStack::applyKeyframeEffects() where we already track whether the "writing-mode" or "direction" property
changes, we ask each processed effect whether they also target a logical property allowing us to determine whether the
resolved animated property changed and ensuring we schedule an update in such a case.

[0] https://drafts.csswg.org/web-animations-1/#removing-replaced-animations

* LayoutTests/imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-replacement-expected.txt:
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::animatesDirectionAwareProperty const):
* Source/WebCore/animation/KeyframeEffect.h:
* Source/WebCore/animation/KeyframeEffectStack.cpp:
(WebCore::KeyframeEffectStack::applyKeyframeEffects):
* Source/WebCore/rendering/style/KeyframeList.cpp:
(WebCore::KeyframeList::containsDirectionAwareProperty const):
* Source/WebCore/rendering/style/KeyframeList.h:
(WebCore::KeyframeValue::KeyframeValue):
(WebCore::KeyframeValue::containsDirectionAwareProperty const):
(WebCore::KeyframeValue::setContainsDirectionAwareProperty):
* Source/WebCore/style/StyleResolver.cpp:
(WebCore::Style::Resolver::styleForKeyframe):

Canonical link: https://commits.webkit.org/256667@main




More information about the webkit-changes mailing list