Title: [256628] trunk/LayoutTests
- Revision
- 256628
- Author
- jacob_uph...@apple.com
- Date
- 2020-02-14 11:05:47 -0800 (Fri, 14 Feb 2020)
Log Message
LayoutTests/imported/w3c:
[Web Animations] Style changes due to Web Animations should not trigger CSS Transitions
https://bugs.webkit.org/show_bug.cgi?id=207760
<rdar://problem/59458111>
Patch by Antoine Quint <grao...@webkit.org> on 2020-02-14
Reviewed by Simon Fraser.
Mark Web Platform Tests progressions.
* web-platform-tests/web-animations/interfaces/Animatable/animate-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/style-change-events-expected.txt:
* web-platform-tests/web-animations/interfaces/DocumentTimeline/style-change-events-expected.txt:
* web-platform-tests/web-animations/interfaces/KeyframeEffect/style-change-events-expected.txt:
Source/WebCore:
[Web Animations] Style changes due to Web Animations should not trigger CSS Transitions
https://bugs.webkit.org/show_bug.cgi?id=207760
<rdar://problem/59458111>
Patch by Antoine Quint <grao...@webkit.org> on 2020-02-14
Reviewed by Simon Fraser.
While we would consider the unanimated style of CSS Animations specifically when considering what the "start" style values (before-change style in spec terminology)
should be when considering whether to start a CSS Transition during style resolution, we would not consider other types of animations, specifically JS-created Web
Animations. However, Web Platform Tests specifically test whether changes made using the Web Animations API may trigger transitions, and until now they would because
the RenderStyle used to determine the before-change style was the style from the previous resolution, which would include animated values.
To fix this, we make it so that KeyframeEffect objects now keep a copy of the unanimated style used when blending animated values for the very first time. That style
is cleared each time keyframes change, which is rare, but may happen through the Web Animations API. Then in AnimationTimeline::updateCSSTransitionsForElementAndProperty(),
we look for a KeyframeEffect currently affecting the property for which we're considering starting a CSS Transition, and use its unanimated style.
If that unanimated style has not been set yet, this is because the KeyframeEffect has not had a chance to apply itself with a non-null progress. In this case, the before-change
and after-change styles should be the same in order to prevent a transition from being triggered as the unanimated style for this keyframe effect will most likely be this
after-change style, or any future style change that may happen before the keyframe effect starts blending animated values.
Finally, tracking the unanimated style at the KeyframeEffect level means we no longer to track it specifically for CSSAnimation.
* animation/AnimationTimeline.cpp:
(WebCore::keyframeEffectForElementAndProperty):
(WebCore::AnimationTimeline::updateCSSTransitionsForElementAndProperty):
* animation/AnimationTimeline.h:
* animation/CSSAnimation.cpp:
(WebCore::CSSAnimation::create):
(WebCore::CSSAnimation::CSSAnimation):
* animation/CSSAnimation.h:
* animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::animatesProperty const): Because the backing KeyframeList object may not have been created by the first time we query a KeyframeEffect during
CSS Transitions resolution, we provide a method that will check the values provided by the Web Animations API to determine whether it targets a given CSS property.
(WebCore::KeyframeEffect::clearBlendingKeyframes):
(WebCore::KeyframeEffect::computeDeclarativeAnimationBlendingKeyframes):
(WebCore::KeyframeEffect::computeCSSAnimationBlendingKeyframes):
(WebCore::KeyframeEffect::apply):
* animation/KeyframeEffect.h:
(WebCore::KeyframeEffect::unanimatedStyle const):
* style/StyleTreeResolver.cpp:
(WebCore::Style::TreeResolver::createAnimatedElementUpdate):
LayoutTests:
[ macOS wk2 ] webgpu/whlsl/dereference-pointer-should-type-check.html is flaky failing
https://bugs.webkit.org/show_bug.cgi?id=207779
Unreviewed test gardening.
* platform/mac-wk2/TestExpectations:
Modified Paths
Diff
Modified: trunk/LayoutTests/ChangeLog (256627 => 256628)
--- trunk/LayoutTests/ChangeLog 2020-02-14 19:00:08 UTC (rev 256627)
+++ trunk/LayoutTests/ChangeLog 2020-02-14 19:05:47 UTC (rev 256628)
@@ -12,6 +12,27 @@
2020-02-14 Jacob Uphoff <jacob_uph...@apple.com>
+ [ macOS wk2 ] webgpu/whlsl/dereference-pointer-should-type-check.html is flaky failing
+ https://bugs.webkit.org/show_bug.cgi?id=207779
+
+ Unreviewed test gardening.
+
+ * platform/mac-wk2/TestExpectations:
+
+2020-02-14 Antoine Quint <grao...@webkit.org>
+
+ [Web Animations] Style changes due to Web Animations should not trigger CSS Transitions
+ https://bugs.webkit.org/show_bug.cgi?id=207760
+ <rdar://problem/59458111>
+
+ Reviewed by Simon Fraser.
+
+ Mark that a couple of tests are no longer flaky.
+
+ * TestExpectations:
+
+2020-02-14 Jacob Uphoff <jacob_uph...@apple.com>
+
[ macOS ] http/tests/media/now-playing-info.html is flaky failing
https://bugs.webkit.org/show_bug.cgi?id=206699
Modified: trunk/LayoutTests/platform/mac-wk2/TestExpectations (256627 => 256628)
--- trunk/LayoutTests/platform/mac-wk2/TestExpectations 2020-02-14 19:00:08 UTC (rev 256627)
+++ trunk/LayoutTests/platform/mac-wk2/TestExpectations 2020-02-14 19:05:47 UTC (rev 256628)
@@ -1034,4 +1034,6 @@
webkit.org/b/207732 fast/scrolling/latching/iframe_in_iframe.html [ Pass Failure ]
-webkit.org/b/206699 http/tests/media/now-playing-info.html [ Pass Failure ]
\ No newline at end of file
+webkit.org/b/206699 http/tests/media/now-playing-info.html [ Pass Failure ]
+
+webkit.org/b/207779 webgpu/whlsl/dereference-pointer-should-type-check.html [ Pass ImageOnlyFailure ]
\ No newline at end of file
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
