This functions is for hiding caret in cursor mode on desktop browser
when receiving NS_WHEEL_WHEEL, which is never used on B2G in production.
On desktop browser, a proper wheel scroll cycle begins by NS_WHEEL_START
and ends by NS_WHEEL_STOP, which was covered by gtest. Move the three
marionette test for TouchCaret only.
This is the patch which fixed the bug.
When calling OnScrollPositionChanged in cursor mode, we want the
appearance of the caret to be preserved since the caret might be hidden
due to timeout. We should respect the old appearance of the caret.
Add a marionette test to ensure the caret does not appear due to
ScrollPositionChanged.
The comment reads "No need to consider whether the caret's position is
out of scrollport", which is untrue.
For example, the position of nsCaret might be shifted by typing and be
covered by other elements. So we need to set the appearance of first
caret to NormalNotShown when it becomes invisible.
The special-case was added back when the Fennec dynamic toolbar showing/hiding
behaviour didn't resize the content area. As of bug 1180295 that is no longer
the case, and showing/hiding the dynamic toolbar *does* resize the content area.
Therefore the widget bounds always represents the actual content area and can
be used directly as the composition bounds.
In addition, the special-case code relied on a particular quirk of the Fennec
CSS viewport determination code which was removed in bug 1180267. The quirk was
that the CSS viewport height was always set such that it would cover the
available screen height when the page was zoomed out to the minimum allowed
zoom. This behaviour was technically incorrect as it would ignore any height
properties provided in the meta-viewport tag. Now that this quirk has been
removed, the special-case code breaks because the root frame's height is
independent of the screen height and can result in an incorrect composition
bounds.
The browser.ui.zoom.force-user-scalable pref can be modified by the user from
the Fennec settings screen, and allows them zoom pages despite the meta-viewport
tag that might otherwise restrict zooming. This effectively ignores the effect
of the user-scalable, minimum-scale, and maximum-scale meta-viewport tokens.
In the C++ APZ implementation this has no effect, because the min/max zoom values
are never even read if zooming is not allowed. When this is hooked up to the
Java implementation though, the code expects the min/max zoom values to be
equal to the default zoom values in the case where zooming is not allowed. This
behaviour change therefore facilitates hooking up the ZoomConstraintsClient
to the Java pan/zoom controller implementation, which happens in a future patch.
