Automatic update from web-platform-tests
Treat -webkit-writing-mode as animation-affecting
Since writing-mode is an animation-affecting property, -webkit-
writing-mode must be as well, since it's a surrogate of writing-mode.
There's an underlying bug in the StyleCascade related to animation of
surrogates. For surrogates that are kHighPropertyPriority, the bug
causes a crash, because we're attempting to lookup a property that isn't
being animated. For other properties, it causes the surrogate to
silently not be applied.
Since -webkit-writing-mode is the only high-priority surrogate that
exists, making it disallowed in animations effectively makes the crash
unreachable.
I'll address the greater issue separately.
Bug: 1077501
Change-Id: I5df40337b88a1621ecbe20be04149ca2d6e9dfb8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2181209
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/master@{#765523}
--
wpt-commits: 7de10f60511ace754ac4a0d030416132278ceac3
wpt-pr: 23407
Automatic update from web-platform-tests
Mark two idlharness.html tests as timeout=long
These are symptomatic of crbug.com/1047818, but to stop the pain for
sheriffs lets mark them timeout=long for now.
Bug: 1043453, 1043310
Change-Id: I9773b44e271ffe3a48f195de37c6ad917c01d24c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2171508
Commit-Queue: Luke Z <lpz@chromium.org>
Auto-Submit: Stephen McGruer <smcgruer@chromium.org>
Reviewed-by: Luke Z <lpz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#763793}
--
wpt-commits: 0583eb9233fafc882d5bc3dc925bd6e522c100b7
wpt-pr: 23314
Automatic update from web-platform-tests
getAnimations cleanup with owning_element
This patch uses owning_element of animations to sorting animations in
getAnimations(), aligning the implementation with the spec:
https://drafts.csswg.org/css-transitions-2/#animation-composite-order
Bug: 1070460
Change-Id: I1bc627ffecc8450e1f2ad1cff0fefc12ac3971da
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2139359
Reviewed-by: Robert Flack <flackr@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Commit-Queue: Hao Sheng <haozhes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#763473}
--
wpt-commits: 56c273203cb250902022702481d56539963ea2ff
wpt-pr: 22931
Automatic update from web-platform-tests
Animations modified with setKeyframes must not mask !important
CSS declarations that are !important have higher priority in the
cascade than animation effects. Unfortunately the information about
which declarations were and weren't important is lost once the
StyleCascade disappears. Specifically, it's not stored on the
ComputedStyle. This causes a problem (once again) for the base computed
style optimization, since we can't naively add animation effects on
top of the base anymore. We might be overwriting something in the base
that was important.
The previous attempt at fixing this (flag on ElementAnimations) doesn't
work properly. For example, it fails to detect the case where an
animation initially doesn't conflict with important declarations, but
then suddenly does via setKeyframes.
To solve this, this CL stores a bitset containing information about
important declarations alongside the base ComputedStyle on
ElementAnimations. When we're considering whether the base can be used
or not, we then check if there's any animation matching the set of
important declarations.
Persisting that many bits is slightly uncomfortable, but the only
viable alternative I see is disabling the optimization when *any*
important declaration exists in the base, which is probably a worse
option.
Sidenote: Initially I tried to always use the base, even when there
were conflicts with important declarations. The bitset of important
declarations is effectively a set of animations to be skipped, so we
should still be able to use the base if we just don't apply the
properties present in the set. However, it unfortunately didn't work
due to visited/unvisited colors being animated together
(crbug.com/1062217).
Bug: 552085
Change-Id: I39e2879af8a858ce1bd97eaa2ceb6e222591df79
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2152449
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#761034}
--
wpt-commits: 9f16de83abdee864d6dafebbacc298b08964750d
wpt-pr: 23032
Automatic update from web-platform-tests
Animations modified with setKeyframes must not mask !important
CSS declarations that are !important have higher priority in the
cascade than animation effects. Unfortunately the information about
which declarations were and weren't important is lost once the
StyleCascade disappears. Specifically, it's not stored on the
ComputedStyle. This causes a problem (once again) for the base computed
style optimization, since we can't naively add animation effects on
top of the base anymore. We might be overwriting something in the base
that was important.
The previous attempt at fixing this (flag on ElementAnimations) doesn't
work properly. For example, it fails to detect the case where an
animation initially doesn't conflict with important declarations, but
then suddenly does via setKeyframes.
To solve this, this CL stores a bitset containing information about
important declarations alongside the base ComputedStyle on
ElementAnimations. When we're considering whether the base can be used
or not, we then check if there's any animation matching the set of
important declarations.
Persisting that many bits is slightly uncomfortable, but the only
viable alternative I see is disabling the optimization when *any*
important declaration exists in the base, which is probably a worse
option.
Sidenote: Initially I tried to always use the base, even when there
were conflicts with important declarations. The bitset of important
declarations is effectively a set of animations to be skipped, so we
should still be able to use the base if we just don't apply the
properties present in the set. However, it unfortunately didn't work
due to visited/unvisited colors being animated together
(crbug.com/1062217).
Bug: 552085
Change-Id: I39e2879af8a858ce1bd97eaa2ceb6e222591df79
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2152449
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#761034}
--
wpt-commits: 9f16de83abdee864d6dafebbacc298b08964750d
wpt-pr: 23032
Automatic update from web-platform-tests
Base style should respond to animations modified with setKeyframes
When animating font-affecting properties (e.g. font-size) while the
base style contains font-relative units (e.g. em), we can not use the
base computed style optimization, since the font-relative units in the
base must respond to the font animation.
A has_font_affecting_animation_ flag was recently added to
ElementAnimations to assist in disabling the optimization under these
circumstances. However, that was added with an insufficient
understanding of ElementAnimation's lifetime, and hence this flag
doesn't really work properly.
For example, if we have an animation that initially doesn't affect the
font, but then suddenly affects the font after all via setKeyframes,
we would paint one incorrect frame before discovering that the font
is now affected, and then (for frame #2 and subsequent) we'd be able
to disable the optimization.
This CL instead checks if the EffectStack affects the font when we're
considering the base computed style for use.
Bug: 437689
Change-Id: If07f1e82559673433be0a80d2c3edea1c1a5165a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2139662
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/master@{#759197}
--
wpt-commits: f16078c799c17f920a1328347f99588b10dfea5f
wpt-pr: 22914
Automatic update from web-platform-tests
Add the owning_element to CSSTransition class
The patch adds owning_element to CSSTransition class. Now the
CSSTransition have an owning_element and we will clear the owning
element if the animation disassociate from the owning_element.
The next follow up patches will enable us to use owning element to
compare the composite ordering. And a clean-up will required to fixed
the previous work-around due to no owning element.
As per spec: https://drafts.csswg.org/css-transitions-2/#owning-element
Bug: 1043778
Change-Id: Ic034ae25a39bacdab0bddbcc4a2ebab1a8a65a57
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2121453
Commit-Queue: Hao Sheng <haozhes@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Reviewed-by: Majid Valipour <majidvp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#755522}
--
wpt-commits: c725fc33e6efd6267047e3327cd945cef8be3f66
wpt-pr: 22588
Automatic update from web-platform-tests
Fix a bunch of links to specs that are not or no longer correct (#22591)
--
wpt-commits: 7dd40e82414995002e8a9c20a167db0efac628d5
wpt-pr: 22591
Automatic update from web-platform-tests
Let StyleCascade own MatchResult and interpolations
There is currently a bug where font-relative units in the base style
are not responsive to font-affecting animations (even with issue 437689
fixed) _if_ the element hits the MatchedPropertiesCache. This can
easily happen if two identical elements (with the same MatchResult)
undergo the same CSS animation.
The reason this bug exists is in StyleResolver::
CascadeAndApplyMatchedProperties. Notice that, when
cache_success.IsFullCacheHit() is true in that function, we return
immediately, and never Analyze the MatchResult. In other words, the
MatchResult is _there_, fully populated (we're using it as the cache
key after all), but we never let the StyleCascade actually Analyze it,
which is the source of the bug. When we later apply animations
(see StyleResolver::ApplyAnimatedStandardProperties), we Analyze the
animations/transitions _only_. This was done on purpose, as too much
Analyzing is expensive. Hence, during ApplyAnimatedStandardProperties,
I assumed that either:
- We would hit the base computed style optimization, and hence the
MatchResult would be empty, and there is no need to analyze it, or
- We would not hit the base computed style optimization, and the
MatchResult object would be populated and Analyzed already.
But of course, I forgot about the third option: based computed style
optimization miss, but a hit on the matched properties cache. In that
case the we have a non-empty MatchResult that haven't been Analyzed.
To fix this, we could have simply Analyzed the MatchResult in
ApplyAnimatedStandardProperties (potentially a second time). But this
is inefficient. I don't want to do that.
Instead, this CL moves the MatchResult ownership (and
CascadeInterpolation ownership) to StyleCascade itself. It also adds
flags which tells us what needs to be analyzed. Using this, we can
now analyze-on-demand during Apply, which means we analyze exactly the
amount we need to analyze, also in the case where an animation frame
hits the MatchedProperties cache.
It also makes for a far more sensible (but still not perfect)
StyleCascade API, compared to "manually" analyzing.
Note that this CL also removes filtering Analyze-time. This means
that e.g. for ::marker, we add declarations to the CascadeMap that
we know aren't going to be applied (as they are filtered in the Apply
step). This is because analyze-on-demand is not easily compatible with
this kind of filtering. For example, when dealing with inherited-only
cache hits, we first try to apply the inherited properties only.
If the font or zoom was modified, we need to apply the non-inherited
properties after all. And for that second apply pass, we obviously need
all properties to have been analyzed before, not just the inherited
properties.
Bug: 1065387, 437689
Change-Id: I7e9b7f33fc12f055603e789d3ae700d5a7a3dbbf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2124649
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/master@{#754457}
--
wpt-commits: 724eb3d3feb35cb1d762b9196842917aafaf0399
wpt-pr: 22527
Automatic update from web-platform-tests
Let base style respond to font animations
Whenever we are animating a property that affects the font, we must
avoid the base computed style optimization. This is because the base
style may contain em, ex (etc) units which needs to resolve against
the font.
Hence, set a flag when a font-affecting animation is applied.
Bug: 437689
Change-Id: I8bd950a1df9c8e100c4ca2b7318b0389a2acfad0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2109694
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#752498}
--
wpt-commits: d12a254011ec967f8f72ba5d380b932a2d7912e8
wpt-pr: 22331
Automatic update from web-platform-tests
Let animations/transitions use the main cascade
In order to solve difficult problems such as crbug.com/552085,
interpolations must be applied using the same cascade as where the
MatchResult was analyzed. This means we'll skip applying the
interpolation if an !important declaration exists for the same
property.
This CL:
- Moves the MatchResult out of ElementRuleCollector. MatchResult must
now be passed to ApplyAnimatedStandardProperties, hence it must
outlive ElementRuleCollector.
- Lifts the on-stack StyleCascade up to StyleForElement, such that it
can be used in both ApplyBaseComputedStyle and ApplyAnimated-
StandardProperties.
- Sets as flag on StyleResolverState when an interpolation effect is
skipped during Apply. This means something was !important, and we
can't use the base-computed-style optimization.
- Clears the base-computed-style if the above flag is set.
- Due to how the base computed style optimizations works when DCHECK
is on, it was necessary to add Reset functions to StyleCascade and
MatchResult (see explanation near MaybeResetCascade).
This is a web-facing change: !important declarations will now override
declarations in the animation origin. WPT for this was apparently non-
existent, so this CLs adds a few tests (that also pass in Firefox).
Bug: 552085, 985049
Change-Id: I538f73936e96e1bd974e0855b081e99bf947e6a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2064248
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#752476}
--
wpt-commits: a94e269aea2aeb21da3c210e50213a874beba71d
wpt-pr: 22315
Automatic update from web-platform-tests
Add timeouts for EventWatchers on CSS animation tests (#22282)
Previously the test harness could timeout while waiting on the event
watcher. In this patch, a timeout was added to the watchers in cases
where the events should fire on the next animation frame. With the
change, we still see timeouts on individual tests, but no longer see
the test harness timing out.
Next steps:
1. Add animationcancel. For some reason, this event got overlooked
previously and was never implemented. Adding this event resolves
the majority of timeouts (confirmed in an experimental patch).
2. Reconnect and event delegate after calls to animation.effect.
Currently, the lack of a delegate on the new effect halts the
dispatching of subsequent animation events.
Bug: 1059968
Change-Id: Ib5bf46762e316a5f3d5f33aa95bf74edaf42e773
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2105424
Reviewed-by: Yi Gu <yigu@chromium.org>
Commit-Queue: Kevin Ellis <kevers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#750745}
Co-authored-by: Kevin Ellis <kevers@chromium.org>
--
wpt-commits: c1c943f3d9e3fe023e401a39db1a66e535a50561
wpt-pr: 22282
Automatic update from web-platform-tests
Fix Flaky Composite Order test
This patch fixes the flakiness in getting running-animation order by
making sure the animation is running before we make a measurement.
This test passed all 500 repeated run.
Bug: 1060216
Change-Id: I8b271e1e0d31dac0203aa3a7bb3359f7f1d1eec6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2099474
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Commit-Queue: Hao Sheng <haozhes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749528}
--
wpt-commits: bb7e53928c77ab258efbd4023cf8687fed27a4c7
wpt-pr: 22202
Automatic update from web-platform-tests
Implement composite order with animate preempting css
In this patch, we replace the current implementation of sorting effect
order by comparing effect sequence number with comparing the
HasLowerCompositeOrdering function.
The patch will align the implementation with the spec
(https://www.w3.org/TR/web-animations-1/#the-effect-stack). And as we
are using the same comparison function as the getAnimations, the
rendered result would be the same as getAnimations() result.
Bug: 1050224
Change-Id: I88f151fa78070817d2fa4fd520580ddf6d024e27
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2076160
Commit-Queue: Hao Sheng <haozhes@chromium.org>
Reviewed-by: Majid Valipour <majidvp@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#748492}
--
wpt-commits: c33c94f3b1977e8f04447f159ea3483d232745e2
wpt-pr: 22124
Automatic update from web-platform-tests
Ship @supports selector()
Unfortunately, some animation tests are now failing, because the tests
use CSS.supports to query for ::marker support, and change their
behavior to include ::marker animations. Animating ::marker is currently
not allowed by the spec, and therefore not supported by Blink.
I2S: https://groups.google.com/a/chromium.org/d/topic/blink-dev/MVXTnyC_4bQ/discussion
Bug: 979041, 1054509
Change-Id: Ib97bec4b4ef9e83598543b6d77bc48e434c6180a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2064930
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#745427}
--
wpt-commits: ea450feb1189f9f53d16c2a01f90aa97c75eb99b
wpt-pr: 22017
This corresponds to the approach outlined in https://github.com/w3c/csswg-drafts/issues/4822
Specifically:
* Calling play() / pause() always triggers the "animation play state is being
overridden by the API" behavior (unless the method throws an exception).
* Setting the startTime or calling reverse() only triggers this override
behavior if it results in a change between a playState that is paused and a
playState that is not paused.
Differential Revision: https://phabricator.services.mozilla.com/D65100
--HG--
extra : moz-landing-system : lando
We will use this in the next patch to test the result after calling setKeyframes.
Differential Revision: https://phabricator.services.mozilla.com/D65096
--HG--
extra : moz-landing-system : lando
Automatic update from web-platform-tests
Replace some "promise_rejects(t, 'SomeDOMError', stuff)" calls with promise_rejects_dom.
This diff was generated by running:
find . -type f -print0 | xargs -0 perl -pi -e "BEGIN { \$/ = undef; } s/promise_rejects\(([ \n]*[a-zA-Z_]+[ \n]*,[ \n]*)([\"'][A-Za-z_]*[\"']) *(, *.)/promise_rejects_dom(\1\2\3/gs"
in bash (doesn't work in tcsh, due to the $ inside "").
--
wpt-commits: b7f2dd315a8d84ce786f6336510ee51423011009
wpt-pr: 21600
Automatic update from web-platform-tests
Test that CSS animations composite in their animation-name order.
This adds a WPT test verifying that CSS animations are composited in the
order of their name within the animation-name property.
Bug: 1045835
Change-Id: I8e746e1841cd4f5ca55e3e067762c2ea93e5c101
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2022616
Auto-Submit: Robert Flack <flackr@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Commit-Queue: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736825}
--
wpt-commits: 80c04f7d1db0d311f46eb44abfd321cacb36192f
wpt-pr: 21437
Automatic update from web-platform-tests
Order animations of same class by tree-order of their owning elements
Currently, getAnimation sort the result by animation class and creation
time.
Sort composite order for animations of the same animation class by tree
order of their owning element according to spec.
(https://drafts.csswg.org/web-animations/#dom-document-getanimations).
This patch align the implementation with the spec.
Bug: 993365
Change-Id: I8478b2985c0ab473db33c176fc69516ea0222ee1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2008325
Commit-Queue: Hao Sheng <haozhes@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735966}
--
wpt-commits: b671b5021721154c2a31cfebfddc8f7d76c77b62
wpt-pr: 21357
Automatic update from web-platform-tests
Replace some "assert_throws(new FooError(), stuff)" calls with assert_throws_js. (#21354)
This diff was generated by running:
find . -type f -print0 | xargs -0 perl -pi -e 'BEGIN { $/ = undef; } s/assert_throws\(([ \n]*)new ([A-Za-z]*Error) *\(\) *(, *.)/assert_throws_js(\1\2\3/gs'
and then:
1) Manually adjusting fullscreen/rendering/fullscreen-pseudo-class-support.html
to test for the right sort of exceptions ("SyntaxError" DOMException, not a JS
SyntaxError).
2) Manually adjusting performance-timeline/po-observe-type.any.js to test for
the right sort of exceptions ("SyntaxError" DOMException, not a JS
SyntaxError).
3) Manually adjusting performance-timeline/po-observe.any.js to test for
the right sort of exceptions ("SyntaxError" DOMException, not a JS
SyntaxError).
4) Manually adjusting user-timing/mark_exceptions.html to test for the right
sort of exceptions ("SyntaxError" DOMException, not a JS SyntaxError).
5) Manually adjusting user-timing/measure_syntax_err.any.js to test for the right
sort of exceptions ("SyntaxError" DOMException, not a JS SyntaxError).
6) Manually adjusting domxpath/lexical-structure.html to test for a
"SyntaxError" DOMException, since that's what all browsers throw and there is no
clear spec for this.
7) Manually adjusting workers/constructors/Worker/Worker-constructor.html to
test for the right sort of exceptions ("SyntaxError" DOMException, not a JS
SyntaxError).
8) Backing out the changes to resources/idlharness.js because some tests pass
objects from a different window to it, and we end up with the wrong TypeError
constructor in those cases.
This does affect indentation poorly in cases when the first arg was on the same
line as the assert_throws, there was a newline after the ',' after the first
arg, and the following args were lined up with the first arg. Fixing that,
especially when there are multiple lines after the first arg, is not trivial
with a regexp.
Co-authored-by: Boris Zbarsky <bzbarsky@mit.edu>
Co-authored-by: Stephen McGruer <smcgruer@chromium.org>
--
wpt-commits: 2c5c3c4c27d27a419c1fdba3e9879c2d22037074
wpt-pr: 21354
Automatic update from web-platform-tests
Rework keyframes-remove-documentElement-crash.html to not use testharness.js (#21052)
Previously this test would fail when loaded locally as the
testharness.js cleanup code would try to access
document.documentElement, which had been removed. Instead, use the
crashtest support
(https://web-platform-tests.org/writing-tests/crashtest.html).
Fixes#20020
--
wpt-commits: 12f1eb104c6b5036f133778113adac50f7bca2bf
wpt-pr: 21052
There are multiple places where bogus non-empty transition rules can be created
before this patch when EffectSet's cascade information isn't up-to-date. That
can happen as described in bug 1606176.
Anyhow, in this particular call site, this is only used to filter from
transition rules effects that are from running animations, to implement:
https://drafts.csswg.org/css-transitions/#application:
> Implementations must add this value to the cascade if and only if that
> property is not currently undergoing a CSS Animation ([CSS3-ANIMATIONS])
> on the same element.
In the test-case, the EffectSet cascade info is empty, so we hit the "skip
everything" for animations (wrong), and "skip nothing for transitions" (also
wrong). This creates a transition rule node which then we never remove
(understandably, as the element never had a transition!).
This fixes the observables of this test-case, by checking the cascade level
(so that we don't create transition rule nodes with declarations coming from
animations). This is strictly more correct than what we were doing.
If we hit the proposed assertion after this change, this code may still create
transition rules that incorrectly override animations, but will never mint one
out of the blue which we'd then fail to remove (which is the problem the
test-case is hitting).
Differential Revision: https://phabricator.services.mozilla.com/D58333
--HG--
extra : moz-landing-system : lando
Automatic update from web-platform-tests
update WPT tests to eliminate CSSPseudoElement from animations (#20040)
Goes with spec CL https://github.com/w3c/csswg-drafts/pull/4437 (merged)
Eliminated the use of CSSPseudoElement from WebAnimations to coincide with
recent spec changes. JeyframeEffect targets now use an Element reference
and pseudo-element selector like getComputedStyle and css-animations events.
Change-Id: Ib6957a7b764eac3b4372ad35c1b79b139c356a19
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1894477
Reviewed-by: Stephen McGruer <smcgruer@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Commit-Queue: George Steel <gtsteel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#714541}
--
wpt-commits: 2f837d2e318b64f66ee8da1f3b798b03b697d4d7
wpt-pr: 20040
Automatic update from web-platform-tests
Fix the test descriptions in animation-fill-mode-001/003-manual.html
The css animation color's gradual changes in the tests
only include the two colors, yellow and green, not blue.
When the gradual color change is finished, the color goes back to blue.
The test descriptions could confuse the tester running this test cases,
this patch changes it.
--
wpt-commits: d89f2fcb5a3848ab24801b1f3fcc144b785869fa
wpt-pr: 19967
Differential Revision: https://phabricator.services.mozilla.com/D53526
Automatic update from web-platform-tests
No need to invalidate style in an empty document.
InvalidationRootForTreeScope() assumes we have documentElement() for the
document scope. Exit early from @keyframes invalidation if it's null.
Bug: 999522, 999521, 999524, 999656
Change-Id: Iec34f4871087c50fd2d067d955f26e3eb02536b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780724
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#692443}
--
wpt-commits: 580bc2dba627bfe2e9b81c254d32b76e90a9c24f
wpt-pr: 18786
Automatic update from web-platform-tests
Move computed transition-timing-function test (#18412)
The test for transition-timing-function computed
value should be under CSS Transitions, not
CSS Animations.
--
wpt-commits: 3db7e8efd19657f6b30fdb7ad7bf7d0f651214fc
wpt-pr: 18412
--HG--
rename : testing/web-platform/tests/css/css-animations/parsing/transition-timing-function-computed.html => testing/web-platform/tests/css/css-transitions/parsing/transition-timing-function-computed.html
Automatic update from web-platform-tests
CSS: WPT for animation-name computed value
animation-name computed value is the specified name(s), or none.
https://drafts.csswg.org/css-animations/#animation-name
Change-Id: I6e602f9fc218d44a40b693a44713ad958330fbb6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1741341
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#684765}
--
wpt-commits: 185cb65b3988d213fd59a18cd4e53f2ba1f8719c
wpt-pr: 18309
Automatic update from web-platform-tests
[cssom] getComputedStyle not getComputedValue (#17799)
Fix typo in test titles.
--
wpt-commits: 9daa6ffd6eb28afb0940b7ac304b08e8383fc527
wpt-pr: 17799
Automatic update from web-platform-tests
CSS Animations: WPTs for responsive animations
column-rule-color animations respond to changes in currentColor
and inherited column-rule-color that occur while the animation
is in progress.
column-width animations repond to changes in font-size
and inherited column-width that occur while the animation
is in progress.
Note this test fails in
Edge 18
Firefox 67 (partially)
Safari 12.1
Bug: 812908
Change-Id: Ic28819a7f4aa3c8c30b11d58ea2600563a182c07
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1689612
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#675042}
--
wpt-commits: 3c5c83759bb5062de405b1c29257f89e884759fb
wpt-pr: 17658
This is the easy fix.
The hard fix (outlined in the comment) would be nice, but I don't think this bug
alone justifies it.
Differential Revision: https://phabricator.services.mozilla.com/D38184
--HG--
extra : moz-landing-system : lando
This patch produces the following serialization:
```
input | computed value
------------------------------
1. "auto" "auto"
2. "auto auto" "auto"
3. "15px auto" "15px"
4. "15px" "15px"
```
i.e. If the second value is 'auto', then it's omitted from our serialization,
because it's implied.
Besides, we update the wpt to address this spec issue:
https://github.com/w3c/csswg-drafts/issues/2574
Differential Revision: https://phabricator.services.mozilla.com/D35510
--HG--
extra : moz-landing-system : lando
Automatic update from web-platform-tests
CSS Animations: timing function computed value WPT
Web Platform Tests for animation-timing-function and
transition-timing-function computed value.
Bug: 893397
Change-Id: Ia590b4b540580ad8d25dd263b2ab04e27f103747
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1647299
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Auto-Submit: Eric Willigers <ericwilligers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#668136}
--
wp5At-commits: 1f9fc8ede0b1577fee15f569b953a430766cad7d
wpt-pr: 17245
Automatic update from web-platform-tests
WPT/BGPT: Add animation stop and set time tests, make css-animations tests threaded.
This patch does a couple of things:
1. Adds a test to test opacity and transform animations being paused with time
explicitly set.
2. Adds a virtual threaded test suite for css-animations (adds ~57 new tests).
R=wangxianzhu@chromium.org, chrishtr@chromium.org
Change-Id: Ica53a46f1efba38537dad29dc0a99bbf57892808
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1569348
Commit-Queue: vmpstr <vmpstr@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#651356}
--
wpt-commits: 7e98f7c6953f824080bb78c289d5b63edbd4b6f7
wpt-pr: 16364
Automatic update from web-platform-tests
Add <meta name=timeout content=long> to WPT in SlowTests
This is the 2nd step in the process of banning external/wpt from
SlowTests. After cleaning up the wtp entries we're marking them as
slow by using wpt idioms, i.e.:
1) Add <meta name="timeout" content="long"> to .html files
2) Add // META: timeout=long to .js files
Bug: 765026
Change-Id: Iaf051104f419524916e19324996cc36ee37d5426
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1497005
Commit-Queue: Sergio Villar <svillar@igalia.com>
Reviewed-by: Andy Paicu <andypaicu@chromium.org>
Reviewed-by: Robert Ma <robertma@chromium.org>
Cr-Commit-Position: refs/heads/master@{#643402}
--
wpt-commits: 7287608f90f6b9530635d10086fd2ab386faab38
wpt-pr: 15630
Automatic update from web-platform-tests
Add <meta name=timeout content=long> to WPT in SlowTests
This is the 2nd step in the process of banning external/wpt from
SlowTests. After cleaning up the wtp entries we're marking them as
slow by using wpt idioms, i.e.:
1) Add <meta name="timeout" content="long"> to .html files
2) Add // META: timeout=long to .js files
Bug: 765026
Change-Id: Iaf051104f419524916e19324996cc36ee37d5426
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1497005
Commit-Queue: Sergio Villar <svillar@igalia.com>
Reviewed-by: Andy Paicu <andypaicu@chromium.org>
Reviewed-by: Robert Ma <robertma@chromium.org>
Cr-Commit-Position: refs/heads/master@{#643402}
--
wpt-commits: 7287608f90f6b9530635d10086fd2ab386faab38
wpt-pr: 15630
In particular, this tests the composite order of ::marker pseudo-elements and
dispatching cancel events for these elements.
It adds one test that is known to fail in Gecko. This will be fixed in the next
patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D28175
--HG--
extra : moz-landing-system : lando
This may or may not be part of the plan to get rid of nsCSSValue ;)
Option is not usable via FFI, and they should not be needed (we should be
following the shortest serialization principle instead). These patches also do
that, which matches the other transform properties. I think that slight change
is fine, if we can make it work, and consistent with other properties.
Alternative is adding more TransformOperation variants or such, which I rather
not do.
Differential Revision: https://phabricator.services.mozilla.com/D21862
--HG--
extra : moz-landing-system : lando
