This constant is better located in SuggestedWords.
Or it could be in Constants, that would be fine too.
Bug: 8636060
Change-Id: I3e721bb1e2559f028dce8929eceadfe0478c5924
This is fine because getKey{X,Y} is idempotent for any
non-keyboard coordinate value.
However this makes a net change : the x,y values passed to
LatinImeLoggerUtils.onNonSeparator are now different.
The point is however that they used to be wrong. The logged
values used not to account for the keyboard padding that
is present on tablets, and in the simulating tools we don't
know about that padding so we couldn't use the coordinates.
The catch here is that other calls like LoggerUtils.onSeparator
should follow suit, but this is too big a change to do it at once.
Follow-up changes will fix them too.
Bug: 8636060
Change-Id: If4b3d3cb1ed4b44c35f23e66aba3b5797236bba7
No need to test multiple times for this. Let's just never do useless
stuff, and only test for that once.
Bug: 8636060
Change-Id: I50a9e4da769fbec44fbb12eedfed03aad924cc2c
For edit tasks, the estimate is actually the right thing to use.
This is really dangerous, but it will get rid of pretty much all
race conditions.
Change-Id: I2d5ca3ce45e32f1bd9c8b778421fd54b9c1f6f63
This just mirrors what InputLogic#tryFixLyingCursorPosition
is doing. That method will go away in the next change.
Change-Id: Ifa2827dbc1f1d20e2c642d6f2d23514a01ed9203
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
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 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
