The new Java compositor only handles scrolling the top-level scroll-frame. Use
browser.js to detect when a sub-frame is being scrolled and send an 'override'
event to Java to tell it to pass us scroll events instead of calling the
scroll function on the LayerController.
Send an event to scroll to the focused input field when the
soft keyboard comes up. Ensure that this happens *after* the
viewport change event is sent to Gecko, so that Gecko actually
knows that browser viewport is smaller and doesn't just no-op
the scroll request.
Don't allow Gecko to set the viewport size because Java knows
this better. Allowing this behaviour could result in Bad Things(TM)
under certain race conditions such as described in bug 707285.
Calculate the viewport size based on the user-visible content area
and the zoom factor, rather than relying on the screen size, since
the screen size doesn't take into account things like the URL bar
and android chrome that may be visible.
The velocity filter patch from bug #705114 changed how displace worked during
panning, but this accidentally changed how it worked in some non-panning
situations (such as at the end of a fling or snap animation).
If the Java code is in the middle of a fling when Gecko sends
a viewport update, abort the fling, cancel the velocity, and
re-fling. The re-fling is purely to get the page snapped to an
edge if needed.
Force a viewport update to Java when there is an in-page
navigation, as this will change the scroll coordinates.
This includes splitting the existing sendViewportUpdate
function into two - one that does the update and the other
that just does the send.
Missing pieces of the document resulted in pageWidth getting
assigned to NaN, which was serialized as null by JSON. This
resulted in an exception over in Java-land when deserialization
was attempted, and killed the viewport update entirely.
Set the render mode to RENDERMODE_WHEN_DIRTY and request a redraw when a layer
transaction ends and when the viewport in LayerController changes. This stops
us from drawing continuously.
Certain devices, such as the HTC Flyer, deliver motion events with identical
coordinates before a touch-release event. This causes kinetic panning to fail,
as the calculated velocity is only based on the last two events.
Introduce a velocity change factor, so that the velocity can only change by a
certain amount per event. This has the effect of smoothing velocity changes
and fixes the bug on the HTC Flyer, at least.
