We now call NotifyAsyncPanZoomStarted/Stopped precisely on the document
which is being transformed, so we no longer need to notify the child
docshells which was added in Bug 1088559.
Remove the |nsIDocument| argument for ProcessAPZStateChange(), which is not
used anymore.
mActiveAPZTransforms added in bug 1142926 is removed because AccessibleCaret
is the only consumer for AsyncPanZoomStarted/Stopped, and it now defaults to
always show while scrolling, i.e.
"layout.accessiblecaret.always_show_when_scrolling" defaults to true. And I
cannot reproduce the bug even if I turn off the preference.
MozReview-Commit-ID: DiEk2gCIHn2
This patch prevents the Windows widget code from dispatching the contextmenu
event if APZ is handling touch input. Instead, the APZ code processes the
raw touch input, and will fire a contextmenu event when the user lifts their
finger after a long-press action, in keeping with the Windows platform
convention. Doing it this way also allows us to respect web conventions where
the web content can prevent the contextmenu event from firing by calling
preventDefault on the touchstart event; this was not possible when dispatching
the contextmenu event directly from the widget code.
This also makes long-pressing on browser chrome components work properly, as
it just shifts the point in time that the contextmenu event is fired without
changing any of the code that triggers the XUL popup. However, some changes
were needed to have the widget code ignore the synthetic mouse events that
the Windows platform sends us, because those would otherwise immediately
dismiss the contextmenu popup after it appeared.
MozReview-Commit-ID: 9HFZLC6xUAi
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
For B2G we had this "special" behaviour where a long-press that didn't trigger
a contextmenu or whose contextmenu event was cancelled would still trigger a
click event. No other browser does this, and so I think it doesn't make sense
for us to keep doing it either. It also makes it much harder to implement the
Windows-style contextmenu, where the contextmenu pops up when you *lift* your
finger after doing a long-press.
MozReview-Commit-ID: K7NmkNbjfqY
