This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
The bulk of this is adjusting the code that tries to use the toolbar to
have appropriate null checks instead of asserting it will exist. The
creation of the animator instance is now guarded by a IsFennec
condition.
Depends on D8658
Differential Revision: https://phabricator.services.mozilla.com/D8659
This extracts code that is conceptually unrelated to the dynamic toolbar
from the dynamic toolbar codebase. It is a stepping stone to being able
to not instantiate the AndroidDynamicToolbarAnimator at all for
non-Fennec android products.
Differential Revision: https://phabricator.services.mozilla.com/D8657
This patch removes the 'ScreenOrientationInternal' type from
dom/base/ScreenOrientation.h and moves it into the
HalScreenConfiguration.h header, renaming it simply to 'ScreenOrientation'
in the process. This has several knock-off effects:
- It allows files that needed ScreenOrientationInternal to include a much
smaller header than before
- It greatly reduces the number of headers pulled in when including Hal.h
- It clarifies the role of the type. The 'Internal' part in the name had
nothing to do with it being part of the implementation. The type was public
and called that way only to avoid clashing with the 'ScreenOrientation'
class. Since we moved it into a different namespace it can be renamed
safely.
- It allows a file that was manually re-declaring 'ScreenConfigurationInternal'
type to use the original one
- Finally this fixes a few files which were missing headers they actually
required but that would still build because unified compilation put them into
units that already had those headers thanks to ScreenConfiguration.h
Differential Revision: https://phabricator.services.mozilla.com/D4458
This results in fixed position elements being attached to the layout viewport
when being async-scrolled by APZ (when the layout viewport is larger than the
visual viewport).
MozReview-Commit-ID: 2YYIDnTWgVn
Includes a new RAII class: AutoApplyAsyncTestAttributes, which, for the
duration of its lifetime, applies mTestAsyncScrollOffset and mTestAsyncZoom to
the APZC's FrameMetrics. We need this to ensure that the
AsyncPanZoomController::GetCurrentAsync* methods consider test scroll and zoom
attributes when doing their respective computations.
MozReview-Commit-ID: 9owJcdIegNH
That's because the shadow base transform value might have been changed by APZC.
The test case in this patch fail without this fix on non-WebRender and the test
case is skipped on WebRender since the bug should never happen on WebRender
because WebRender manages animation transform value and APZ transform value
separately.
MozReview-Commit-ID: Itgh0QL1su6
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
When we send play-pending animation to the compositor, we resolve its start
time with the time at the very moment we send the animation to the compositor
instead of refresh drivers' tick time. That means that it's possible that the
start time indicates more future time stamp than the previous frame time stamp
on the compositor. If we were to use the previous frame timestamp in this
case, then we'd end up treating the animation as if it had not yet started so
we would skip its initial paint.
MozReview-Commit-ID: 8TdZ6m0gqMm
Before this change, the value which was set by SetShadowBaseTransform()
has been used for the assertion, but it is possible that the value is changed
by APZ. And it's hard to tell whether the value has been changed by APZ or not
and it's hard to *reverse-calculate* the differences in the past APZ at the
moment we want to do the assert.
So after this patch, on debug build we don't actually skip the calculation for
unchanged animations and use the newly calculated value for the assertion.
MozReview-Commit-ID: 8fCcvvbUMHe
Note that we have to calculate animation values if there is another animation
since the other animation might be 'accumulate' or 'add', or might have a
missing keyframe (i.e. the calculated animation values will be used in the
missing keyframe).
MozReview-Commit-ID: rQyS9nuVJi
In the next patch, we skip updating animation value for the layer if the
animation value isn't changed. So without this patch, we will have to update
animation value even if the value isn't changed at all.
MozReview-Commit-ID: 9tU7BTkNOHL
This was regressed by bug 1420512, which changed things so that
ScrollbarData::mDirection is set for both kinds of scrollbar layers.
MozReview-Commit-ID: 3UHFSOgDtWj
Two AnimationValue are still used in AnimationPropertySegment since the
AnimationPropertySegment is used in compose_animation_segment() which is also
invoked on the main-thread, so we will fix it later in a bug that will drop
AnimationValue usage on the main-thread side.
MozReview-Commit-ID: B086g2qHtZL
This is slightly efficient since we don't need to call
GetBaseAnimationStyle() or we do skip allocating animation data for such case.
MozReview-Commit-ID: BYFNwZsZ1oE
This rolls back a few of the changes from bug 1443792. Although in
theory a LayerMetricsWrapper having an APZC should be equivalent to it
having a scrollable metrics, this might not always be strictly true. For
example, if there is no GeckoContentController registered for a layer
tree, then there might not be APZCs for that layer tree even though it
has scrollable metrics. More importantly, a malicious child process
might be able to trigger scenarios where the equivalence doesn't hold,
and thereby trigger failures in the UI/GPU process.
MozReview-Commit-ID: 1gfbILx7HWU
This makes more sense in APZCTreeManager, but is exposed back to
AsyncCompositionManager via APZSampler. This also makes the APZ code
better encapsulated since the method API exposed on APZSampler doesn't
need to take a AsyncPanZoomController; it can just take the
LayerMetricsWrapper instead.
MozReview-Commit-ID: 9yJJd3x8VhN
ScrollDirection variables for which NONE was a valid value are replaced with
Maybe<ScrollDirection>.
I also took the opportunity to change the remaining ScrollDirection
enumerators to eTitleCase as per style guide.
MozReview-Commit-ID: GWejQR2HqH5
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
The patch removes CompositorBridgeParentBase::GetAnimationStorage and CrossProcessCompositorBridgeParent::GetAnimationStorage, and remove the "aId" parameter to CompositorBridgeParent::GetAnimationStorage, since it's only ever called with "0" as the argument.
