This bug would kill the case where the whitelist contains
a word to be autocorrected to an uppercased version of
itself, and the user would enter the uppercase version.
In this case, this bug would cause the typed word to be
killed off the list of candidates, and possibly autocorrected
to the *next* candidate.
When the whitelist checks whether this the typed word is
a candidate for whitelisting, this change has it check whether
the whitelisting results in the typed word before returning.
Hence, it can keep the case-insensitive behavior of the
whitelist.
Coincidentally, this change renames the method used to do
this, because it does not comply with the general contract
of Dictionary. This happens to be in the way of another
upcoming change.
Bug: 5420371
Change-Id: Ifb305271acc5f171adf9b18c762ae7975b14be0a
When long press triggers caps lock, the keyboard also triggers haptic
feedback.
This change also fixes trivial harmless bug in KeyboardSwitcher.
Bug: 5424681
Change-Id: I62706b49abd7be1dcebc3c5166ea03f426fc8c86
This goes together with I6b8628b9acc32449e4147a2a754b222fbb76c754
or it will break the build
Bug: 5402436
Change-Id: I07c6266b713773a8de80bb22afdd4c566261f78a
This removes the calls, but another change will be needed to remove
the messages LatinIME used to send itself to update the suggestion
strip.
Bug: 5402537
Change-Id: I5d1aa63a892516f339f3ceac21f43771b5ffda34
This change updates suggestions when the cursor is moved.
It is now reasonable to remove the explicit test for
TextEntryState.isAcceptedDefault because it is now shielded
by mExpectingUpdateSelection : actually, this probably fixes
a long-standing bug.
Bug: 5337309
Change-Id: Iee4046420c6a88d1a07d428230f93c3ebef25c39
In effect, this stops the spell checker from suggesting overly
long words.
More precisely, it takes advantage of the new facility that
takes into account the whole length of the dictionary word when
computing scores, so words much longer than the input word will
see their score demoted accordingly.
Bug: 5384578
Change-Id: I326cd7c87c3080e7fa8729f78517f8ba13672a9b
IME is called back four methods for each input field as a IME life
cycle. The four methods are onStartInput, onStartInputView,
onFinishInputView and onFinishInput.
After orientation changed, Those quartet methods will be called back
twice. This behavior of the framework might be a bug.
In order to restore the previous keyboard layout, we should skip
onFinishInputView and onFinishInput of the first quartet and
onStartInput and onStartInputView of the second quartet.
Bug: 4311428
Change-Id: I450ddc0cce5d00abc971ffd42a507a8a86682548
It now follows the following logic:
- If the word should be filtered out => false
- Else => !IN_THE_DICTIONARY
This defines the behavior for ICS MR0, and prepares for addition
of a new HAS_LIKELY_SUGGESTIONS flag in MR1.
Bug: 5383800
Change-Id: I530b1404ae8cf3337ff68ef5ab0f4d95f2dad0e8
The gutter area between the suggestions strip and the top-row keys
looks like a part of the suggestions strip, and the touch events
landing on the area should be forwarded to the suggestions strip.
Bug: 5246673
Change-Id: I92af763be0feed21aa36ceffb5d575abe554f19e
CL https://android-git.corp.google.com/g/#/c/136474 refactored
the fullscreen test, but ithe IME_FLAG_NO_EXTRACT_UI test was
lost in the process.
Note that there is still a problem (orthogonal to that change
with key_preview_backing, which appears opaque and black sometimes.
I'll re-open 5315001.
Change-Id: If3a73179d21eaca10bdc948db7bac4b4f7a88d34
Because "TRHEE DOT LEADER" glyph of Roboto font is broken, we decide
to use "..." instead.
Bug: 5344295
Change-Id: I0fa5eefc00baf80747ff5215c018619a7e15a58e
This change also separates controlling visibility of "key preview
backing view" from suggestions strip visibility.
Bug: 5315001
Change-Id: I190a71f7956c804e5d89d2d5bacecc62d565ac2c
This is a follow up change of If6c0edef.
This is a cherry-pick of Idb415f53 from Master.
Bug: 5328922
Change-Id: I36d8bda9fb95e4809598296226c598a9f08bd8bb
This should not be used lightly, as it violates the general
contract of locale, and does kill some legitimate (albeit
alledgedly rare) use patterns.
Currently, the spell checker uses this because it uses a
negative logic: it should match broadly, and when in doubt,
match even more broadly, which is almost never the case of
something that uses the locale.
In other words: don't use this option unless you are
very, VERY sure that's what you want. Hint: it isn't
Bug: 5280929
Change-Id: Ib3cae319c692161d653630038c5bcde1f4340c05
There is no definite path known for this to end up being
touched by other classes, but we could imagine through
some way or some other it ends up shoved in the stringbuilder
pool, leading to catastrophic results.
Hopefully related to
Bug: 5248688
Change-Id: Ib8abfc31263cbf31d515ed607ced5d8253971938
If the spellchecker encounters a bug and happens to crash,
it may be sensible to avoid killing the keyboard in response.
This is a possible way to do it, which comes with the big
drawback of making bugs in the spell checker harder to find.
Change-Id: Idb26fb592b9718e1dbdadeda8fbd1a8a1d805c28
Note that this affects only the results of the spell checker if
actually passed such a word. For example, the spell checker will
not flag "http://oju" as a typo, because it looks like a URL.
But in the current implementation, TextView passes "http" and
"oju" separately, so "oju" is still flagged as a typo.
Bug: 5281875
Change-Id: I9d721fd3af34edc51b11908cf2e8fe994b164242
The locale is specified by KeyboardLocale extra key in method.xml,
LatinIME will use the specified locale for keyboard layout.
Bug: 5238658
Change-Id: I8e6cb66c73a7ac1bf611d9910b42fa9cff38eba0
Autotext correction would check whether the first suggestion
so far was the same as what Autotext would return, and if it
was indeed the same, would not send its result as
autocorrect. However, the first suggestion is not guaranteed
to have a high enough score to trigger autocorrection, and
there would be cases where a word in autotext would not get
autocorrected because the word came out of bigram
suggestions. These occurrences would be extremely rare, as
they would require concomitant insert between autotext for
one char and bigram suggestion. It is, in fact, probably
limited to the capitalization of "I".
This did not happen in gingerbread because gingerbread would
not register 1-letter words as valid bigrams.
This fix works by just always sending the result of autotext
regardless of whether it is already the first suggestion or
not. This is okay because duplicates are removed afterwards
anyway - and this processing is absolutely necessary because
the autotext'd word may actually be somewhere else in the
suggestion, so it made really no sense checking for only the
first one.
Please note that there is also a race condition that can
result in "i" not being converted to "I": at the moment,
Latin IME relies on having the suggestions evaluated
at the time autocorrection is performed, but when typing
very, very fast, those messages may have been canceled.
This is not limited to the autocorrection of "i", but
affects all autocorrections. It requires a nearly
inhumane typing speed to trigger, but hitting "i" and
space in turn as fast as one can it's possible to
reproduce occasionally.
Bug: 5135113
Change-Id: I530ea6212487300001a2c0fc5b25a5c7716bdf63
satok
Tadashi G. Takaoka
Svetoslav Ganov
Jean Chalard
Alan Viverette
Yusuke Nojima
Ken Wakasa
Fabrice Di Meglio
Gilles Debunne