If a tap is close to, but not on a node, slop allows the tap
to find the node. Pass the slop-corrected values to
requestFocusNodeHref() as well.
bug:3412519
Change-Id: I7543354b6270976e1f99518581de23c567432b98
In viewport setup time, pre-calculate the more likely view scale
and text wrap scale instead of waiting until ZoomManager's FirstLayout
time. This is to give webkit better and more correct information, such
as window width/height and inner width/height, when it is doing first layout.
issue: 3382398
Change-Id: I53fb15da43fbede6c03a4f51ec1c50e9a94f0236
Bug 3329346
Making sure the cursor is never hidden by the finger. Some
vertical movement is not repercuted on the handles' position
if it moves the finger closer to its 'ideal' touch position,
where both the insertion line and the top of the handle are
visible.
Also removed the hysteresis line filter which is not that
usefull and feels sluggy.
Change-Id: I6ad0fed0cf66753c6571b3bc620b1a0f2397c7b2
Bug: 3473996
change getTitleHeight to be protected so that subclass
can override it
use getTitleHeight for rendering
use getHeight for clipping
Change-Id: I6e9a85d88eba176886e53b260d02082d26b410d8
Bug 3482310: The playing state was not being correctly set to
RUNNING after an animator was start()'d. Instead, we were seeking
to the start value (correct), setting the state to SEEKED (also correct),
but not resetting the playing state to STOPPED. So when the animation
actually started animating values, it didn't recognize that it was
starting a STOPPED animation, so it never set its state to RUNNING,
and never returned true from isRunning().
Change-Id: Iea92dce98f92f60052d8a9a451094b953f9f0c67
Remove country code and sleep policy setting back up as it
is a device specific setting
Bug: 3481068
Change-Id: Ifc824c1cd3c3706f8cdaf09b06a05a0c94243acb
Bug 3416154
The origin of the problem is new display optimisations that enable
a scrollView to be scrolled without calling the onDraw method of its
children. As a result, the handles' positions were not updated on scroll.
DropDown popup menu have an integrated scroll listener that will fix the
problem. Using these indead is the first part of the solution.
The next problem is that when they get hidden, these popups try to move their
parent (the TextView in our case) which creates a scroll conflict. Fixed by
overriding findDropDownPosition.
Finally, when the handles get invisible, a new scroll listener has to be
installed that will show them back in case the view is scrolled back.
This is also an important step to fix Bug 3441308 (selectable text in list
views).
Debugging find outs:
Small optimization in PopupWindow to avoir unregistering then registering
back the listener when it is updated.
getHandle().show(); is not needed since updatePosition will do it through
moveTo().
Change-Id: I6bf6a3649538328257734ed1e651b23b889d65d9
