Passing FlingHandoffState around as an in-out parameter was making
the next change (respecting overscroll-behavior) messy.
MozReview-Commit-ID: 4wuoll20Jt7
--HG--
extra : rebase_source : c5d843254a38196547119419d1a2ad1fd0f3ef09
The definition for replace_init is only used in two places:
replace_malloc.h and mozjemalloc.cpp. Invoking the malloc_decls.h
machinery for just that one function is a lot of overhead, and things
are actually simpler doing the declaration directly, especially thanks
to the use of C++11 decltype to avoid duplication of the function
type.
This has the additional advantage that now malloc_decls.h only contains
the allocator API.
While here, replace the MOZ_WIDGET_ANDROID ifdef with ANDROID.
--HG--
extra : rebase_source : 50ddf044f43904575598f17bd4c3477fc1a1155f
Because one entry point is simpler than two, we make replace_init fulfil
both the roles of replace_init and replace_get_bridge.
Note this should be binary compatible with older replace-malloc
libraries, albeit not detecting their bridge (and with the
previous change, they do not register anyways). So loading older
replace-malloc libraries should do nothing, but not crash in awful ways.
--HG--
extra : rebase_source : aaf83e706ee34f45cfa75551a2f0998e5c5b8726
Factory::DoesBackendSupportDataDrawtarget already fulfills the same
purpose and we should use that instead, as imgFrame is the only user of
the former API. It has the added bonus of allowing us to use shared
surfaces on Linux with WebRender, and using volatile surfaces on Windows
when D2D is disabled.
The allocator API is a moving target, and every time we change it, the
surface for replace-malloc libraries grows. This causes some build
system problems, because of the tricks in replace_malloc.mk, which
require the full list of symbols.
Considering the above and the goal of moving some of the replace-malloc
libraries into mozglue, it becomes simpler to reduce the replace-malloc
exposure to the initialization functions.
So instead of the allocator poking into replace-malloc libraries for all
the functions, we expect their replace_init function to alter the table
of allocator functions it's passed to register its own functions.
This means replace-malloc implementations now need to copy the original
table, which is not a bad thing, as it allows function calls with one
level of indirection less. It also replace_init functions to not
actually register the replace-malloc functions in some cases, which will
be useful when linking some replace-malloc libraries into mozglue.
Note this is binary compatible with previously built replace-malloc
libraries, but because those libraries wouldn't update the function
table, they would stay disabled.
--HG--
extra : rebase_source : 2518f6ebe76b4c82359e98369de6a5a8c3ca9967
This is follow-up to bug 1417519, to fix an incorrect change in that bug.
GetAPZCAtPointWR calls things like FindRootApzcForLayersId which require
the tree lock to be held, so we should hold it. It makes more sense to
hold the lock across the whole GetTargetAPZC function since we don't want
tree mutations to happen while we're in this function.
It also means we can't call GetTargetAPZC inside GetAPZCAtPointWR
because that will recursively try to pick up the tree lock; instead we
can use GetTargetNode and get the APZC from that.
MozReview-Commit-ID: 7ZXQMMes8hV
--HG--
extra : rebase_source : 1c9650e6fb720ef26daf63151cd1f6b144aa8ffb
Most of this patch is just mechanical changes, but note that this patch
now makes the mFlags in scrollbar-container nsDisplayOwnLayer instances
have one of the direction bits set. As a result, this requires changing
the implementation of nsDisplayOwnLayer::IsScrollThumbLayer().
MozReview-Commit-ID: 2BLdbpz5Sa8
--HG--
extra : rebase_source : 27e7d90ce60c7f702fe77d8a3a0f7e3ae3e4a4ff
Gecko passes it now, and we want to know if that ever changes.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8349be1b3e768b85fbb09ecb3dd4e9480a24f29e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2582aced86ba89e34fe59bef17af04c8fdb587a6
Hopefully most of these changes are self-explanatory however a few notes follow.
* In timing-model/animations/play-states.html, as well as making the tests match
the updated spec, one or two tests have also been moved to better reflect the
order in the spec (to make it obvious which branch of the algorithm is being
tested).
* In timing-model/animations/set-the-timeline-of-an-animation.html we previously
had two tests that check:
a) That the playState was 'pending' before and after setting the timeline.
b) That the playState was 'pending' before setting the timeline and then,
after setting the timeline and waiting on the ready promise, would become
'running'.
Likewise we had the same test for pausing.
Since these are basically the same test--(b) just adds the wait on the ready
promise--we combine them here into one test that covers both (a) and (b).
MozReview-Commit-ID: CLoDJvsdwmF
--HG--
extra : rebase_source : c2f34fa6614795f2d3ba9ca3e572f11306f96463
Currently we have a test in interfaces/Animation/playState.html that somewhat
randomly tests the result of the `playState` member.
However, there's no complex logic associated with the `playState` member in the
IDL. It simply returns "The play state of this animation". The logic we need to
test is in the definition of 'play state' which is in the timing model.
As a result we move this test to timing-model/animations/play-states.html
However, this test as it stands does not test the calculation of the play state
in a particularly thorough manner. For example, it does not contain a single
test for the 'finished' state.
Given that this patch series will change the definition of the 'play state' we
first fix this test to cover each of the different cases in the definition of
the 'play state' prior to these changes. That is, we update the tests based on
the definition of 'play state' here:
https://www.w3.org/TR/2016/WD-web-animations-1-20160913/#play-states
(Note that at this point in the patch series the pref to turn on the changed
definition behavior has not been enabled even for tests so this patch is
actually testing the behavior when that pref is false. We'll replace much of
this test in the next patch but by updating the test first, we should be able to
more clearly see the changes in the next patch.)
MozReview-Commit-ID: 1xkOmuY1SxD
--HG--
rename : testing/web-platform/tests/web-animations/interfaces/Animation/playState.html => testing/web-platform/tests/web-animations/timing-model/animations/play-states.html
extra : rebase_source : 1890e1b4db007452df393e8a9e4b3ccf42bca237
This reflects the change made to the Web Animations specification in:
9e2053f5531c3415f4cc
(I got it wrong the first time. The second commit fixes the first.)
And discussed in:
https://github.com/w3c/web-animations/issues/196
In summary, we are splitting the "pending" play state out into a separate
boolean member so that it is possible to distinguish between "play-pending" and
"pause-pending" and because most of the time when you check for
animation.playState === 'running' you also really want to include play-pending
animations.
MozReview-Commit-ID: IJSNoZTKW2I
--HG--
extra : rebase_source : 5d17239fd087cfe3cce1c9697eff97d062b6dd4b
