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
This is probably the last thing we will ship since it needs the most spec work.
MozReview-Commit-ID: LLmDBLCsCBJ
--HG--
extra : rebase_source : c06752c9201a9ede87e1ac200ab12577bf784ce6
This feature should not be shipped until the various definitions of addition for
each additive property are properly specified.
Unlike other patches in this series, compositing is not frequently used
internally (e.g. by DevTools etc.) so there is no need to enable this by default
for system code.
Also, it turns out we have inadvertently been shipping part of this feature for
some time now. The next patch in this series will add tests for that case and
disable that part of the feature (a suitable intent to unship will follow). This
patch merely adapts and extends the existing tests without affecting the surface
area covered by the combination of the newly-added pref and the existing
dom.animations-api.core.enabled pref.
MozReview-Commit-ID: Htr6mlyCBav
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_compositing.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_compositing.html
extra : rebase_source : 7715a25e59568eb122ba3f7dbd2c2b2ffdd19954
This preference controls whether authors are allowed to specify animations
without a 0% or 100% keyframe.
We intend to ship this soon but this preference acts as a safeguard in case we
discover we need to disable it.
This feature is very convenient and commonly used so this patch ensures it is
always enabled for system content.
MozReview-Commit-ID: BHTsuS2xO61
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_implicit_keyframes.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_implicit_keyframes.html
extra : rebase_source : 04fd93dd26a4765c14b0b22febdb0311b650ea59
We don't intend to ship this in the near future until the integration with
AnimationWorklet is clear (although we might ship a read-only version).
That said, we use this feature extensively internally (e.g. in DevTools etc.) so
we enable this feature for system callers.
MozReview-Commit-ID: AhB7ZmU1Xzw
--HG--
extra : rebase_source : 630d7dc56b44a9261bb34aa5417cb9b7050efba4
Many tests set the dom.animations-api.core.enabled pref to true when all they
really require are the features covered by the dom.element-animate.core.enabled
pref. Now that we have removed that pref and permanently enabled that
functionality we can drop the annotations from such tests.
MozReview-Commit-ID: CGOLp6pVFLE
--HG--
extra : rebase_source : e298e9404d76d55421d9ca4b514410d02cc243b1
When the pending animation having no target element sets a new effect having
a target element associated with a document, PendingAnimationTracker has to
start tracking the animation regardless of mPendingReadyTime.
MozReview-Commit-ID: DxmbXtLhjCT
--HG--
extra : rebase_source : 46c9a51e7d3b971a0c0ffcf94b579d22450028f5
The function will be used in the case of KeyframeEffect::SetTarget too.
MozReview-Commit-ID: G6ipjxaIJsW
--HG--
extra : rebase_source : 609fa17d698612df21d9cac469e6997582dcca69
Before this change, the test in this commit fails. The received events order
is;
1) cancel
2) transitioncancel
3) transitionstart
4) finish
MozReview-Commit-ID: 8liTFXime6e
--HG--
extra : rebase_source : 3c68ef330b1f263afa2fad9670a30b351b8dbf28
There doesn't appear to be any need to separate these anymore.
MozReview-Commit-ID: GHR259JJHJV
--HG--
extra : rebase_source : e9b15c820df97570c3f6e978a7f0c224e33f0468
This is no longer needed since in bug 1456394 we merged the two types of
KeyframeEffects into one.
MozReview-Commit-ID: 8IuTD9ivAGK
--HG--
extra : rebase_source : b14593b33bfa9a0233b524010b3bde3cfc078950
If we have a rotate axis whose length is extremely large, we will get an
infinite value, and its normalized vector is a zero vector, instead of an
unit vector, i.e. (x/inf, y/inf, z/inf) == (0, 0, 0).
The solution is: we scale the vector, so the length becomes a finite value,
and we could get a valid unit vector. Therefore, we use
a different normalization method, robust_normalize().
MozReview-Commit-ID: L8SteFe09aO
--HG--
extra : rebase_source : 4568c8bf906a9246e4ef13672a9ed541852b974a
There seem race conditions that we do a paint process when we started observing
the refresh driver but the first tick hasn't happened yet.
MozReview-Commit-ID: KRP8WR644q1
This call was added in bug 929362, but the key factor to fix the bug was just
setting a flag representing that the target frame doesn't allow the animation
running on the compositor and checking the flag in the function whether the
animation can be run on the compositor or not in later ticks. So the call
wasn't necessary in the first place.
The test case here fails without this fix. The test case actually doesn't
observe animation restyle count at all, so it might look a bit awkward in
file_restyles.html, if we add other test cases checking SchedulePaint calls
in future, we will move the tests in a different file.
(The reason there is no animation restyles in this case is that we properly
throttle the animation in this case.)
MozReview-Commit-ID: AyHciRJHM0s
--HG--
extra : rebase_source : f3963336ea9165b0a9c1a662bdac5c645b209219
Web animation event (i.e. finish and cancel event) is solely queued.
MozReview-Commit-ID: h1g3NfcY3c
--HG--
extra : rebase_source : 1a7b09783d193195b886fa3a046198ba3e02dd7b
That's because the target for web animation events (i.e. finish and cancel)
is an Animation instance.
MozReview-Commit-ID: 5xR325FXUo
--HG--
extra : rebase_source : 9bd0623ece1dc449d52db283882fe236dbc11c6d
Normally the refresh driver's time changes in nsRefreshDriver::Tick, and then
DocumentTimeline::WillRefresh is called for the change. But nsRefreshDriver
sometimes updates its own time when their timer changes to the active one.
This patch lets DocumentTimeline update animations in response to the refresh
driver's time updates. And thus this patch prevents animation state and
relevant stuff inconsistencies such as an animation has been finished without
proper processes, e.g. without invalidating frame for the animation.
MozReview-Commit-ID: 42p5BWITQN0
--HG--
extra : rebase_source : 58cc7d8e203a3632b6934b9d778e82e2fe208adb
As for removing an entry, EnsureRemoved is equal to what Contains && RemoveEntry
do, but for consistency we use EnsureRemoved here.
MozReview-Commit-ID: 9qE3YtvmwC8
--HG--
extra : rebase_source : 1681194cd8b9700d46a07a502f7d2f15580918aa
Before this change, we don't acend up frame tree across different documents,
but it's possible that subframe document is scrolled out in the parent document,
if there are animations in such subframes, we should throttle the animations
too.
The test case added here fails without this fix.
MozReview-Commit-ID: EdOEVEwomPc
--HG--
extra : rebase_source : 4d6366cf609d9269ec05b3722f5adb21d940a9e3
Because now we don't try to send the animations on visibility:hidden element.
MozReview-Commit-ID: IFqIc8ewz5T
--HG--
extra : rebase_source : ed031b3a55fd89f74437b71812f90dfc1825e823
Even if we unthrottled the invisbile animations to update the overflow region,
we don't need to send the animations to the compositor since the scroll bar
updates caused by the overflow should have been finished before sending
animations to the compositor.
MozReview-Commit-ID: GtKdPfBSyRB
--HG--
extra : rebase_source : 3b15f4578ed60740c1409304fe35ecd4f53fbd5b
Brian Birtles
Noemi Erli
Xidorn Quan
Emilio Cobos Álvarez
Boris Zbarsky
Cosmin Sabou
Nathan Froyd
Hiroyuki Ikezoe
shindli
Boris Chiou
Ciure Andrei
Dorel Luca
Jeff Gilbert