This adds a notification from APZ to the scrollbar's slider frame to
inform it of APZ starting an async scrollbar drag. This is useful
because APZ can start a scrollbar drag and even change the scroll
position before the scrollbar frame even handles the mousedown event. In
such a case, the mousedown can land on where the scrollthumb *used to
be* before it was dragged away. This can result in scroll-to-click
behavior getting triggered and the scrollthumb glitching.
With this patch, the new notification follows the same path as the
request-repaint message, and so is guaranteed to arrive at the scrollbar
before any request-repaint messages. It sets some state that can be used
to correct the behaviour described above.
Differential Revision: https://phabricator.services.mozilla.com/D12364
--HG--
extra : moz-landing-system : lando
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
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
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
--HG--
extra : rebase_source : f0be2be24fce7d0f0ed25f6f3bfab5f7f2864f23
extra : source : fc9898a9ab28cee292e201ddaf757ee267179433
extra : histedit_source : 35415d3dc2c0ae0f269994c385cceff75f150020
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
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
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
--HG--
extra : rebase_source : bc4c6417e77461634263defb88e67ed5036c454e
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
--HG--
extra : rebase_source : 80855ac7d3ae44c393dde96650b330cc737f69d6
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
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
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
