In the case that a touch event is passed to WebKit then back to
WebView, the coordinates will be converted from view to content
then back to view and the convertion could lose some accuracies.
For a flash content that only consumes TouchDown, all the
TouchMove events will go through this path and each time, the
data becomes more inaccurate. Even worse, the TouchMove event
updates the mScrollX/Y which will then be used for the convertion.
The effect amplifies really quick and the scrolling looks jumpy.
The fix is just to store the original view coordinates when pass
the event around.
Change-Id: Ie1424d7cfc6272348b194732e97168efe2dcf17b
WebCore is too slow
Make sure that we can recover properly from a bad gesture with missing
events that never come back from webcore. Lower timeout to 1 second.
Confirm movement on touch event enqueue so that we don't get phantom
taps or long presses when webcore is slow to respond.
Add sanity check in ScaleGestureDetector to end a gesture early on a
bad MotionEvent stream rather than throwing up.
Change-Id: I69690409d7edd6b4320dbcf3b052aba4023360fe
bug:4091160
We no longer allow not shown views to fire accessibility
events. Therefore, CheckBoxPreference can no longer ask its
associated checkbox to fire an accessibility event because
the latter is not attached to the view hierarchy
(i.e. not shown) by the time the CheckBoxPreference has a
chance to send an accessibility event. Instead the
CheckBoxPreference itself is responsible for firing the event.
Change-Id: Ia742882b13bf6c441cc76fa1e84b47a55cee601c
Caused a local reference table overflow, only when deleting a large number
of files in a single SQL transaction in the media provider.
Bug: 4093346
Change-Id: I10078a5d7537c2e577763d88e909e34321945a59
Signed-off-by: Mike Lockwood <lockwood@android.com>
bug:4093343
1. If getting a day from location in a week view fails
the out date was cleared but the client was unaware
of that failure. I have added a return value indicating
where getting the day from locations was successfull.
Change-Id: I566a9ee33dfe2e64300a4b50dacc652114e01442
Bug #4092053
The problem always existed but was made visible by partial invalidation.
When saving a layer, the renderer would try to postpone glClear()
operations until the next drawing command. This however does not work
since the clip might have changed. The fix is rather simple and
simply gets rid of this "optimization" (that turned out to be
usless anyway given how View issues saveLayer() calls.)
This change also fixes an issue with gradients (color stops where
not properly computed when using a null stops array) and optimizes
display lists rendering (quickly rejects larger portions of the
tree to avoid executing unnecessary code.)
Change-Id: I0f5b5f6e1220d41a09cc2fa84c212b0b4afd9c46
