This matches the spec, https://drafts.csswg.org/css-values/#angles, which says:
> All <angle> units are compatible, and deg is their canonical unit.
And https://drafts.csswg.org/css-values/#compat, which says:
>When serializing computed values [...], compatible units [...] are converted into a single canonical unit.
And also other implementations (Blink always serializes angles as degrees in
computed style for example).
Also allows us to get rid of quite a bit of code, and makes computed angle value
representation just a number, which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D8619
--HG--
extra : moz-landing-system : lando
When a compositor animation finishes that doesn't apply a fill, rather than
jumping back to the underlying value immediately we should apply a fill mode
until the main thread has a chance to remove the animation from the compositor.
This ensures that any main thread effects that are intended to synchronize with
the end of the animation have a chance to run before we show the underlying
style and helps to avoid flicker in such cases.
Currently we apply this synthesized fill mode to animations when they run
forwards (i.e. positive playback rate), but not backwards. This patch makes us
apply the same handling when running in reverse.
Differential Revision: https://phabricator.services.mozilla.com/D7259
--HG--
extra : moz-landing-system : lando
According to the new svg 2 spec update (#543), we flip the flag half way for
path interpolation.
Differential Revision: https://phabricator.services.mozilla.com/D6192
--HG--
extra : moz-landing-system : lando
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the
place. Additionally, if moving entries is implemented via memcpy (which
is quite common), PLDHashTable copying around bits *again* is
inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead of
copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
Add tests for ComputeSquaredDistance on |offset-path:path()|.
Depends on D4791
Differential Revision: https://phabricator.services.mozilla.com/D4788
--HG--
extra : moz-landing-system : lando
flushComputedStyle is as follows:
var cs = getComputedStyle(elem);
cs.marginLeft;
That _probably_ flushes style in most engines, but it's possible some engine in
the future will optimize things in a way that it can flush marginLeft without
flushing, say, backgroundColor. Before moving these tests to wpt, it would be
better to explicitly flush the property (or at least one of the properties) we
are transitioning.
This patch also updates the "Setting zero combined duration" test from
test_animation-cancel.html since, in making this change, I realized the test was
wrong.
Specifically, it was testing that when we set a combined duration of zero that
a transition is canceled. However, nothing in the spec requires this. The spec
only requires a non-zero combined duration to _start_ a transition and only
cancels an existing transition if the combined duration becomes _zero_ if the
"the end value of the running transition is not equal to the value of the
property in the after-change style".
This test passed, however, because it changed the transition property to
margin-top, hence it was actually testing the same condition as the previous
test.
--HG--
extra : rebase_source : ab1890c3125cb0a136869cd665efd2aa358304f0
This patch splits the first test into four separate tests since it really seems
to be testing four different things.
Likewise, the later patch for replacing the effect is split into two parts:
- One to test the playState behavior
- One to test the value reported by transitionProperty
The test, "After setting a transition's effect to null, transitionend is still
dispatched", is dropped since it is covered by the last test in
test_event-dispatch.html.
--HG--
extra : rebase_source : dae7ade8a7217e7916930278050b1c9fae847553
This patch merely tidies up some whitespace and uses of quotes / template
strings. There are no substantive changes.
--HG--
extra : rebase_source : 09383565b47c2a6173e1839756058e2b20dfff16
This mostly just tidies up these tests to give them sensible titles.
The only test with major substantive changes is the first test. This test tests
three things:
1) That getAnimations() returns one transition per transitioning property
2) That getAnimations() returns transitions in the order they were generated
3) That CSS transitions have their start time set based on when they were
generated.
(2) is covered later in this file by the test: 'getAnimations sorts
transitions by when they were generated'
(3) is really a test for startTime, if anything, not getAnimations().
I'm not sure how necessary it is, but I've added it to
test_animation-starttime.html for now.
As a result, this patch updates this first test to only cover (1).
--HG--
extra : rebase_source : 992861421e83e8fc391f865888428de22ed16914
This is mostly whitespace tidy-ups. The only substantive change is the fix to
the test description which previously seemed to be missing some words.
--HG--
extra : rebase_source : 9eb84f5a845ece8fe60d5322de6d5f8a6580c370
Apart from obvious tidy-ups the substantive changes to tests in this file are as
follows:
* Skipping forward through animation
-> This is really testing two things:
(a) That you can seek a transition using the start time.
(b) That seeking a transition using the start time triggers
dispatching events.
This patch splits the above into two separate tests.
* Skipping backwards through animation,
-> All these tests are really just exercising event dispatch which is
already covered by test_event-dispatch.html.
As a result this patch drops these tests.
* Setting startTime to null
-> Covered by 'Setting an unresolved start time sets the hold time'
in wpt/web-animations/timing-model/animations/setting-the-start-time-of-an-animation.html
* Animation.startTime after pausing
-> Covered by 'Pausing clears the start time'
in wpt/web-animations/timing-model/animations/pausing-an-animation.html
--HG--
extra : rebase_source : ed598e907085d1cb06ef2142d6471eec4a34300d
The test: 'A new ready promise is created each time play() is called the
animation property', is covered in:
web-animations/interfaces/Animation/ready.html
by the 'A new ready promise is created when play()/pause() is called' test.
As a result, this patch removes that test.
--HG--
extra : rebase_source : 61059b90fec505784b9df67c9b8a2962ca45204b
This seems to be adequately covered by:
web-animations/timing-model/animations/pausing-an-animation.html
(specifically the last test: 'The animation's current time remains fixed
after pausing')
web-animations/timing-model/animation-effects/simple-iteration-progress.html
(which checks that the iteration progress is correctly calculated from the
current time)
--HG--
extra : rebase_source : 58fc61afb9ae638568f17950723bdba0c758c6a5
For the first test, we really want to check that it is possible to restart
transitions (since they are otherwise disassociated once they finish) hence this
patch updates the test to the actual output in style rather than timing.
The second test is covered in
web-animations/timing-model/animations/reversing-an-animation.html
by the 'Playing a finished and reversed animation seeks to end' test so this
patch removes it from this file.
--HG--
extra : rebase_source : 415b8c9ca314085e64ffc715bf72046db264cf52
This patch basically completely rewrites this file to make it simpler and remove
unnecessary tests.
In particular:
* It sets the duration and delay to 100s to match what we use in most tests
* All the helper methods at the start are inlined into the relevant tests
because doing so makes the tests much easier to read and debug.
* The first two tests are combined and extended
- Testing the initial current time is zero is not generally useful but it is
when we're testing setting it
- What the second test really wants to test is that the style updates (i.e.
you really can seek a transition, not just that the currentTime value
updates)
- The trick where we set the start time just to get out of the pending state
seems unnecessary, we may as well just wait on ready. In fact, we don't
_need_ to do that, but this test is about checking you can seek a transition
in motion.
* In the fourth test, 'Skipping backwards through transition', we don't check
the event is dispatched since that is covered in test_event-dispatch.html
in the 'Active -> Before' test.
* The final test, 'Animation.currentTime after pausing', is covered by
web-animations/timing-model/animations/pausing-an-animation.html
--HG--
extra : rebase_source : 113af8f3e4b4f2ffe90cb9bb87be3c2e72a82289
We're a bit inconsistent about this, but generally we try to keep this files as
minimal as possible.
There is still a lot of other cruft in the starttime and currenttime test files
but we will remove that when we tidy up those files in later patches in this
series.
--HG--
extra : rebase_source : 93ef290315b4650650de960551ff07572ff7656e
As part of this change, the "Restart transition after cancelling transition
immediately" test in test_event-dispatch.html needed significant changes.
The reason is that this test was calling:
watcher.wait_for([ 'transitioncancel',
'transitionrun',
'transitionstart' ]);
However, it was not waiting for the result of that call and hence was not
actually checking if the events were being dispatched. And, they are not.
There are two problems. Firstly, this test cancels the transition by setting
display:none. However, transitions don't run on display:none elements so
attempting to restart the transition will not generate transition events.
This might be a bug, but it is not a recent regression in any case (I tested
back to Firefox 54).
However, this test does not require using display:none to cancel. There are
_many_ tests that check that display:none generates a transitioncancel event.
This test only needs to make the transition idle. As a result, this patch makes
that test call transition.cancel() instead.
However, even with that change this test will not pass because it sets
a transition-delay of 100s (presumably so that it does not need to check for
a transitionstart event). As a result this test should not wait on _both_
transitionrun and transitionstart but just transitionrun.
--HG--
extra : rebase_source : a0af0928fd5668b23c92bd8ca142d4b8e99f5429
This patch also drops the checkStateOnSettingCurrentTimeToZero function since it
is no longer used.
--HG--
extra : rebase_source : bd4fdb9368d55b120c839330dbd90a0a89464370
This change also renames several related functions, as well as fields,
and the header is moved into EXPORTS.mozilla given it is defined under
mozilla namespace.
MozReview-Commit-ID: LqCdcW8fmUN
--HG--
rename : layout/base/ScrollbarStyles.cpp => layout/base/ScrollStyles.cpp
rename : layout/base/ScrollbarStyles.h => layout/base/ScrollStyles.h
extra : rebase_source : 8933f3bca88d5db4b9508e3947f695ecf7511b3e
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle
that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the place.
Additionally, if moving entries is implemented via memcpy (which is
quite common), PLDHashTable copying around bits *again* is inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead
of copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
The applying change hints are the same as what we apply for transform style
changed from something to 'none'.
All test cases pass with this fix fail without the fix.
MozReview-Commit-ID: 7HStU26lRPq
--HG--
extra : rebase_source : 701361d477ab7954ab15fde75fd40d98724e47b3
All test cases here pass without any changes on the current trunk, but all
counter part test cases for transform introducing in a subsequent patch will
fail without the proper fix.
MozReview-Commit-ID: 3hgsVfFJPrZ
--HG--
extra : rebase_source : 535b74c6ddb070af1b1803d966a94bf7ae7bd37d
background-color animations will run on the compositor. So we have to change
the property in tests which suppose that background-color animation runs on the
main-thread.
The reason why we use z-index is that the property produces only
nsChangeHint_RepaintFrame, thus it's throttled and won't be unthrottled
periodically on out-of-view elements just like background-color animations.
MozReview-Commit-ID: LZYs0qOGskh
--HG--
extra : rebase_source : f299e46a293db067f771ebd50be34ba9460e8ea7
As discussed here:
https://github.com/w3c/csswg-drafts/issues/2691
We have a similar check in SetCurrentTime (with the exception that, according to
the spec, this behavior applies to either play OR pause pending, instead of just
pause-pending) so this patch tries to match the comment and format of that
check.
Differential Revision: https://phabricator.services.mozilla.com/D2410
--HG--
extra : rebase_source : 519a976424b021203a369926344c2174662e6156
We don't need to hold the strong reference in DocumentTimeline::ToTimeStamp().
MozReview-Commit-ID: 85UQBoPTjfA
--HG--
extra : rebase_source : 43f957d5b6cb9a2ed0db7105b23c634b04d10bc2
It would be easier to understand what happens.
MozReview-Commit-ID: 5lidrbNBzFm
--HG--
extra : rebase_source : d4f1e75928cee449f98ee8224b8740b2ba0f9898
Diego Pino Garcia
Emilio Cobos Álvarez
shindli
Brian Birtles
Boris Chiou
Zibi Braniecki
Nathan Froyd
Olli Pettay
Noemi Erli
Xidorn Quan
Boris Zbarsky
Cosmin Sabou
Hiroyuki Ikezoe