This is more correct. When predictions, the typed word should
always be null unless explicitly passed. The text color should be
that of a valid typed word only if it's actually the typed word.
Bug: 13170509
Change-Id: I769ae100e112c37c6f02064fe9ef2f81372ca9e5
This fixes the color of the predictions when running
on a theme that has different colors for typed and
suggested words (GB theme).
Also, this is easier to understand and to modify from
now on.
Change-Id: Ifdc6d86a1695e83e16103041b06a2451f8d52cc4
In the practice it works because this never tries to access
inside the suggestion strip, and the worst that can happen
is a wrong text color for a suggestion. But since the two
colors that would be swapped are the same, nobody ever
notices -- unless they are using the GingerBread theme.
Change-Id: Ic8c70d8b3cdddf92946dfefbbc6d061572626c7a
File descriptors will be closed in
BinaryDictionary.finalize(); but, this leads to unit test fails.
Bug: 13066902
Change-Id: I2b0d3e54ee91fa844530df54596f86bbbbac81a5
We already have a mechanism to avoid this crash, but it wasn't
used every time it needed to. It's possible that ending a batch
input and starting a batch input happen while suggestions
are being pulled out, which would result in pointers that have
been reset being passed for trimming.
Just increasing the sequence number should get rid of the
problem.
Bug: 12178124
Change-Id: I36ef3bc8a78679bc09daa39e665f5ce1bab50c2a
The heuristic in RichInputConnection makes little sense
when textLength > mExpectedSelStart but we have
more than 1024 characters of text. If there are that many,
it's about 100% sure that 1024 is not the correct cursor
position. With no good guess, we'll just continue trusting
the app, even though we know it's lying : at least it will
make the problem visible to the app author.
Also, there have been a lot of confusion about initialSelStart
and initialSelEnd. The keyboard should log them so that
it helps us and editor authors debug more easily these
common problems.
Issue #65170 in AOSP and
Bug: 12772035
Change-Id: I6665a16c9f2832d33ee323f033bb38bcc092a3b4
When the cursor is moved by the user, the RichInputConnection
is told about it. However, to work around a framework bug, it
also looks at how many characters are in the buffer before the
cursor, and if that's more than the value it's been passed, it
deduces that's a framework bug and there are at least as many
characters as seen before the cursor, so it puts the expected
cursor position there.
When you move the cursor, TextView calls onUpdateSelection,
and when you move it fast, you'll get rapid-fire calls to
onUpdateSelection. This is fine, the RIC is equipped to
deal with that.
However, these calls take some time to make it to the IME. In
this instance, when the first call gets through and the IME
calls TextView (synchronously) for text before the cursor, the
cursor has already moved in the app, and TextView returns more
characters than the cursor position was declared to be in this
instance, so the RIC sets that as the expected cursor position.
Sure enough, a split second later, the second call to
onUpdateSelection arrives, with the new cursor position set
where the RIC had found it too early. The RIC takes that as an
"expected" cursor move, and the input does not get reset.
Luckily, we have a way out. As far as we know, the framework bug
only manifests itself upon rotation, which means we should only
have to adjust for it in onStartInputView. Doing it in
onUpdateSelection is too zealous (and probably too distrustful of
the app to send the correct cursor positions).
So we should just take care of the rotation case (by calling
tryFixLyingCursorPosition in onStartInputView) and remove the
compensating code in resetCachesUponCursorMoves.
Bug: 12982502
Change-Id: Ic3c1408a1ec45deaea63b01d98376a79ae567d77
Because the previous personalization settings default value was on,
this CL changes the preference key of the personalization settings.
Bug: 10587358
Change-Id: I80233e8af4b532d8c67d8fb184c2865862bb35dd
Some were never closed, other closed twice. This change
makes all Cursor instances behave, having the #close()
call in a finally{} clause, and puts the burden of closing
the cursor squarely on the creator rather than in the
called methods.
There is however one exception that is beyond the scope
of this change: UserDictionarySettings have a Cursor
member, it's never closed, and fixing the problem is not
obvious. This change adds a TODO for now.
It's not very clear if this change actually helps with
bug#12670151, but it may be related and it's a good
think to do anyway.
Bug: 12670151
Change-Id: I87cc44387e7dee3da1488671b93a28d9d73f7dc0
During recorrection, the cursor position when calling
commitText is not necessarily at the end of the
composing text.
Besides, RichInputConnection assumes the cursor is
always after any composing text. This is not correct,
but in the practice, it seems all code paths work.
We should fix this in the future.
Bug: 13060691
Change-Id: I15f71fff62d36e80cf6e4a022c5e78af634b199d
This CL also
- removes icons on important notice title.
- changes the "Personalized suggestions" summary text.
This change must be checked in together with Id115d89ba9.
Bug: 10587358
Change-Id: I52ff26fa8ae12445e9014ba08253f69e1be609f4
Some apps depend on the keyboard sending something to them
when the text is empty. This is BROKEN. Your app must not lie
to the keyboard about what is before the cursor. If there is something
to delete, you must not pretend there is not and try to catch some
delete event. This will result in a bad user experience. This will not
work with all IMEs. If your app needs this broken behavior, you're
doing it wrong. Seriously guys, we're not in the era of typewriters
any more, there are touch screens, there are gestures, there is
accessibility, there are many innovative IMEs that don't have
keys. Do *NOT* rely on key events.
This change implements an ugly hack so that these broken apps
may continue half-working with LatinIME. We are very unhappy
about this.
Bug: 12998568
Change-Id: Ia62ae2fbee4fee65b463acf3a79aafcfd0defa1d
This change also fixes Bug#12982404; displays the suggestion word
using entire suggestions strip if there is only one suggestion.
Bug: 12564279
Bug: 12982404
Change-Id: I51806b90c3ee34a2072880245d4e33f7be273c8f
This fixes two separate problems:
- The word finds itself with two separate suggestion spans.
This is fine for LatinIME, but it's hard to predict whether it's
fine for other interested parties (other keyboards).
- The test for the blue underline was incorrect.
Change-Id: I3ecc849676851bf25a25238d694adaa956521a26
