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
FrameMetrics is currently used in about three ways.
1. Main thread to APZ transactions
2. Storing information in AsyncPanZoomController
3. APZ to main thread repaint requests
There's overlap in the use of fields in all these use cases, but it's not perfect. In a
following commit, I'd like to change the information used for (1) to support relative
scroll offset updates. This information isn't needed for (2) or (3), so it would be
good to refactor FrameMetrics out into these use cases.
This commit refactors out (3) as it is fairly easy to do. I'd like to refactor (2) out
as well, but that is trickier. I'd like to leave that for a future followup.
Differential Revision: https://phabricator.services.mozilla.com/D7127
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
A couple of RemoteContentController methods get called on the controller
thread in the GPU process. This is the same as the compositor thread so
we could just do compositor-thread stuff here, but we will want to
support the controller thread being the main thread instead of the
compositor thread. So we detect those cases and bounce the message
accordingly.
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 two happening at the same time can lead to the APZ autoscroll being
cancelled due to APZ receiving a main-thread scroll offset update.
To achieve this:
- The content process assumes APZ is handling the autoscroll until
told otherwise.
- If the parent process knows APZ won't handle an autoscroll, it
tells the content process via its response to the Autoscroll:Start
message. This covers all cases where APZ doesn't handle the
autoscroll, except the case where APZCTreeManager itself rejects
the autoscroll and it lives in the compositor process rather than
the parent process.
- If APZCTreeManager rejects an autoscroll and it lives in the
compositor process, it sends an 'autoscroll-rejected-by-apz' message
to the content process.
MozReview-Commit-ID: L62v4COai6W
The notification is sent via GeckoContentController, PAPZCTreeManager if
necessary (to go from the GPU process to the parent process), and the
observer service.
Naturally, the notification is not sent in the case where it's browser.xml
that initiates the shutdown.
MozReview-Commit-ID: IAaSf4HiDF4
This version of the Dynamic Toolbar moves the animation of the toolbar
from the Android UI thread to the compositor thread. All animation for
showing and hiding the toolbar are done with the compositor and a static
snapshot of the real toolbar.
MozReview-Commit-ID: BCe8zpbkWQt
Sending it back via the parent process ensures that it will take the same path
that regular touch events do, and so guarantees that the Tap event won't overtake
the touch events and get dispatched to content first.
MozReview-Commit-ID: 8TiHY2PFPvE
The parameter is always true if the tap type is a eSingleTap and false in
all other cases, so it's redundant. As it was added as an optimization in bug
1020199 removing it should be safe.
MozReview-Commit-ID: IPB8BUagQl6
There were a couple of problems when delivering tap gestures to content with
full zoom applied. One was that the ConverToGecko function converted the coords
into "CSS pixel" space by using the web content's CSS-to-LD scale, but also
applied that on the translation from the chrome area. Moving that conversion
to later in the process (after the coords got passed through TabParent::
AdjustTapToChildWidget) corrected that issue.
The other problem was that bits of code in APZEventState and APZCCallbackHelper
were using the widget->GetDefaultScale() value as the CSS-to-LD scale, but that
omitted the full zoom value. Getting the CSS-to-LD scale from the presShell and
propagating that through corrected that issue.
MozReview-Commit-ID: KdrkdEZslHo
