InputConnectionHandler really doesn't belong in the gfx package, and
the code to call key event handlers really doesn't belong in LayerView.
This patch refactors things, so that InputConnectionHandler is renamed
to org.mozilla.gecko.InputConnectionListener, and the interface is now
used by GeckoView instead of by LayerView.
InputConnectionHandler really doesn't belong in the gfx package, and
the code to call key event handlers really doesn't belong in LayerView.
This patch refactors things, so that InputConnectionHandler is renamed
to org.mozilla.gecko.InputConnectionListener, and the interface is now
used by GeckoView instead of by LayerView.
InputConnectionHandler really doesn't belong in the gfx package, and
the code to call key event handlers really doesn't belong in LayerView.
This patch refactors things, so that InputConnectionHandler is renamed
to org.mozilla.gecko.InputConnectionListener, and the interface is now
used by GeckoView instead of by LayerView.
The default zoom value is only used on the Java side to clamp the min/max zoom
values in the case where zooming is disabled. We can do this much earlier in
the flow, when we are computing the metadata, and reduce the amount of
redundant information being passed around.
--HG--
extra : commitid : AdyBXqXiIaW
On Gingerbread devices (Android API 9 or 10) the ViewHelper.setTranslationY code
doesn't work to move the SurfaceView. In order to acheive that effect I turned
LayerView into a ScrollView with a dummy element at the top, and allow it to
scroll. This allows the SurfaceView to move as desired. A few places in the code
were assuming that the LayerView and SurfaceView were always at the same screen
location (which was true before but not any more) and so those sites needed
some updating as well.
--HG--
extra : commitid : Jpr1k74MOAD
GeckoThread.LaunchState now covers the entire GeckoThread lifetime and
not just launch, so it's renamed to GeckoThread.State. More utility
methods are added to check for the current state.
There is some ambiguity about whether ScheduleComposite will necessarily
trigger a composite all the way to nsWindow::DrawWindowUnderlay. Android
robocop tests assume it will, because they rely on DrawWindowOverlay
being called so they can take a screenshot and make progress,
but this is a very fragile assumption. They also rely on the entire
window being painted, which is also a fragile assumption.
This patch improves the situation by explicitly invalidating the current
window area when Android Java code needs to trigger a composite. This avoids
regressions from future patches in this series which make composition bail
out when there is nothing invalid.
The resulting setup is still a bit fragile for my taste but I'm not sure
what the ideal solution would be.
--HG--
extra : commitid : 3t3xqRdZs24
extra : rebase_source : b23749613663ca805484776ccf5e36b4ff00e3fe
Before, we'd run this animate the dynamic toolbar over a specified duration
even if the dynamic toolbar was not actually animating anywhere. Thus, this
patch reduces excess work when the dynamic toolbar is not scrolled out of
place (e.g. onPanZoomStopped, onLocationChange, onTabChanged). This reduced
work includes allocating the RenderTask only when we need it.
--HG--
extra : commitid : 3tswkPeE27
extra : rebase_source : e0ffbbfdb8f60e80ef96372d71693aa2ee0490bc
This should hopefully improve power consumption and make us act closer to the
system scrollbars.
--HG--
extra : commitid : HibXXfEknav
extra : rebase_source : 6b4df1252df1c4e7fe4fb718214565289c001657
