This is the first step in using these functions without having a
LayerManagerComposite at all.
MozReview-Commit-ID: 2zkuB7Ox4Ut
--HG--
extra : rebase_source : b23988275f5851a2fd30bd3e8a9931107a224c66
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
This patch moves FatalError to IProtocol. I had to make a few changes.
- I added a ProtocolName() method to find the name of the protocol.
- I gave the two-argument version of FatalError its own name. Otherwise
C++ doesn't like there to be two virtual methods with the same name
in cases where one is overridden and the other isn't (as happens
in IToplevelProtocol).
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.
This patch moves FatalError to IProtocol. I had to make a few changes.
- I added a ProtocolName() method to find the name of the protocol.
- I gave the two-argument version of FatalError its own name. Otherwise
C++ doesn't like there to be two virtual methods with the same name
in cases where one is overridden and the other isn't (as happens
in IToplevelProtocol).
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.
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
We were always uploading the entire texture region, but still by using
glTexSubImage2D. In most cases it should be quicker to use
glTexSubImage2D on the updated region only. And where that function has
problems we should avoid it by making CanUploadSubTextures return false
so that glTexImage2D is used instead.
MozReview-Commit-ID: BrobWEPJ82M
--HG--
extra : rebase_source : 986642a1d7bfe2bcb0cc12dc8e41c17ac77abc1d
Only DirectUpdate was actually being used, so remove the dead
code. TextureImageCGL does't do anything over BasicTextureImage any more
so remove it too.
MozReview-Commit-ID: D7jpC9M7aTT
--HG--
extra : rebase_source : 7846439aa5cb320704b8f811f3203fe7fd31c51e
If, within a single refresh driver tick, the scroll position is updated by JS
explicitly, and then subsequently also updated by a frame reconstruction, the
scroll origin from the former (nsGkAtoms::other) can get clobbered by the latter
(to nsGkAtoms::restore). The restore scroll origin is "weaker" in that it can
be ignored by the APZ code in some circumstances. This is undesirable because
it means the JS scroll update also gets ignored. This patch ensures that when
setting the scroll origin we don't do this clobbering of stronger origins with
weaker origins.
MozReview-Commit-ID: DA4EHp1Debu
--HG--
extra : rebase_source : 99fd1f91698a605792b2a622450f1ff31bc89101
We are forcing a crash when we fail to bind a texture to a
framebuffer. Although it is not clear why this step is failing, crashing
is too drastic an action.
Instead, return nullptr as is done for every other possible failure
during this function. Also log a gfxCriticalError, which will hopefully
allow us to find the cause of the failure at some point, while not
crashing for release users.
MozReview-Commit-ID: H1RlFz8ZVbU