bbb5d6e256675199c21f0bb621e6233acc3418a6
setSelection() was called twice by onTouchEvent, once to the previous position, and then to the new position (unless the IME got displayed, so that in that case the cursor is not moved). The second call was actually triggering a call for a scroll of 0 since view is already displaying the cursor. This scroll is filtered out by a shortcut in ScrollView. The first setSelection's scroll does not have the same issue (since the previous cursor's position is out of screen and requires a scroll) and it then applied, effectively moving the cursor to a new position but the scrolling to the previous position. The fix is to call setSelection only once, after the IME has been asked to display. The cursor is moved to the old/new position depending on the resultCode in onReceiveResult in CommitSelectionReceiver. Bug: http://b/issue?id=2778954 Change-Id: I0983fdf18993e63b230e093e703f95efe6e2d7a8
…
…
…
…
am
0b16e6a0: am 7f0a1f62: am 5f11e95f: docs: small edits to catchup to edits made in html pushed live
…
…
…
am
c05c83e2: am f3c6c982: am 3242cc27: Merge "TimedEventQueue is apparently important for glitch-free media playback, and so having it inherit its priority from the thread that created it is a bad idea. Instead, set the priority explicitly, and bump it to slightly hig
…
…
…
…
…
am
3f704e98: am 801700b1: am 57f4503e: Work on issue # 2778549: Idle FRF72 is awake 18 mins more than ERE27 in 13hr test
…
…
…
Description
No description provided
Languages
Java
73.7%
Kotlin
14%
PowerBuilder
5.8%
C++
5.2%
AIDL
1%