Don't use absolute cursor positions when making edits,
this leads to race conditions.
This is a bit ugly and will need to be fixed soon. Plans are
underway to clean this up.
Bug: 12390573
Change-Id: I69c09fc41b979880d0800c55a710e39373287cff
This is conflicting with later changes. Temporary revert for cherry-pick.
This reverts commit 0b593ce858.
Change-Id: Id53eadb023a950cfcca496c0cfbfe583c7ec7b8c
Don't use absolute cursor positions when making edits,
this leads to race conditions.
This is a bit ugly and will need to be fixed soon. Plans are
underway to clean this up.
Bug: 12390573
Change-Id: Ib42d4149343c642b1b5c1937b424e8afdbd4cc1f
InputPointers.getTime(int) has a validity check of time values. And
the check is enabled when LatinImeLogger.sDBG is on. Such situation
may occur while unit testing. This change ensure that time values are
monotonic while unit testing.
Change-Id: I9ff2cff2bcd253de0e8206dd3be964fe565170fa
This old method doesn't even re-read the old suggestions. It used to
recompute them without the coordinates.
Re-using the recorrection code, which is much more advanced, is
the right thing to do here.
Also, refining the test. It's no use trying to resume suggestion
if we don't have a suggestion strip, since we aren't going to
auto-correct anything anyway.
Not the motivation for this change, but this also fixes
Bug: 11620256
Change-Id: Id49efa32e293c49837c61fdc752c86bbac1d2c88
This method is confusing with the *Locked convention, and
the two-step call creates a useless callback object. This is
better inlined both for readability and for performance.
Bug: 8636060
Change-Id: I7c427c3ca4e831388a6d54de6728b32206a45d80
The only point of this message is to send the processing on another
thread. However, this will be accomplished later.
Here is the exact call graph:
0. onUpdateBatchInput
1. -> MSG_UPDATE_GESTURE_PREVIEW_AND_SUGGESTION_STRIP
2. -> updateBatchInputSync
3. -> getSuggestedWordsGestureLocked
4. -> MSG_GET_SUGGESTED_WORDS
5. -> LatinIME#getSuggestedWords
The point of both step 1. and step 4. is to make sure the processing
is happening on the InputUpdater thread. Thus, it's useless to do
it twice.
Bug: 11326092
Bug: 8636060
Change-Id: Iceebb9e8879a8f15b73c987f5fd3489f27699be4
This sheds some light on what's happening here. Some
comments were at least misleading, maybe indicating something
is not sequenced as intended.
Bug: 8636060
Change-Id: Ia74feb457a39fe4a672c27fe4203264fda940f04
