Moves OnProcessingError, OnChannelError, OnChannelConnected so that they're
only generated for toplevel protocols. For some reason APZCTreeManagerChild
implemented OnProcessingError. I'm not sure what the intention was there so
I removed it.
Currently all our protocols inherit from IProtocolManager<IProtocol>. I have
no idea why. This patch switches everything over to IProtocol, without any
templates. I had to move ReadActor to the .cpp file to avoid redefinition
errors.
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
When calculating the max scroll position, the size of mCompositionBounds is
subtracted from the size of mScrollableRectangle. Unfortunately, the former is
in ParentLayer units and the latter is in CSS units. This causes the final
scroll position to become staggered relative to the mouse when user zoom is not
100%.
Use cssCompositionBounds, mCompositionBounds transformed to CSSRect, which
changes based on zoom. Additionally, refactor GetAxis* functions to return
typed units, where possible.
MozReview-Commit-ID: Ec9cOMP1cdT
--HG--
extra : rebase_source : 1af911a91fe4d13c8563d3c086ac688ec65d2f3c
The test in helper_bug1162771 dispatches a touchstart on an element, and then
inside the touchstart handler makes that element display:none. It then sends a
touchend at what should be the same position. However, since the position of the
touch is calculated from the position of the element, the touchend position can
be wrong because the element is set to display:none in between. This patch
saves the position before sending the touchstart, and makes sure to use the
same position for the touchend.
MozReview-Commit-ID: GoyQvNJ1wRZ
--HG--
extra : rebase_source : 10fbd5d306aa36b46196758d672fce72347ca638
When using the InjectTouchInput API on Windows, the API requires that the caller
keep providing input frames (by calling the API function) at least every 100ms.
If the caller fails to do so, Windows can return an ERROR_TIMEOUT and throw
away the touch sequence. In some tests, it is hard for us to make this guarantee,
because we need to wait for other events between the touchdown and touchup. For
these tests, we can use the widget-level touch injection code that we have as
a fallback for the OS-level touch injection code. The widget-level touch
injection is less representative of real-world usage but allows us to bypass
the timeout problem.
MozReview-Commit-ID: EoVUSZmERUw
--HG--
extra : rebase_source : 4f7ca1a1e6da4479d51526e8f132f5cb23fceb49