Previously MainLogBuffer#shiftOutWords() assumed it wouldn't be called if
mNumWordsUntilSafeToSample was 0. This relaxes this assumption (which is in fact
false in the current code).
Change-Id: I8723248095e84a0d9d6f4639b4742cc7dda9716b
This is about as ad-hoc as it gets, but then again, what we want
is probably as ad-hoc as it gets.
All URL boxes I know of double as search bars, and not adding
automatic spaces there sucks (e.g. in Chrome URL bar).
And in other boxes actually you don't want to add a space if
it looks like a URL. QSB isn't even a search box, and it behaves
like this.
So I think this is actually the right answer to the problem.
Bug: 7062925
Change-Id: Ib09472b34644fd5bf2dc84bb97cedeeba28bcd02
The only place where it's used is checked for nullity.
Also, it's possible, also difficult, to match a different
recapitalize with the old code, triggering a bug that
this fixes.
Change-Id: I717d6df489025c75d1caca290a9086c3b39a9306
Upon pressing Shift, if there is currently a selected string, have
Latin IME change its capitalization.
This does not yet have the keyboard mode follow the mode - the change
is complicated enough as is.
Bug: 7657025
Change-Id: I54fe8485f44e04efd72c71ac9feee5ce21ba06f2
If the user gestures a word, then hits backspace in
disapproval, and gestures about the same thing again,
make sure that we don't suggest the same thing again.
Bug: 7549311
Change-Id: I793bc4df7c3841fa8f2f4146707c26e873f374c1
There are two problems here. The first one is the tests would send
an invalid unicode character. Although we could want dicttool to
handle this more gracefully, it's fine for now.
The second problem is much more serious. If a node has more than
128 children, then the java code will crash trying to read the
dictionary back because of a bug that this change fixes. In
theory, it's possible that happens when we try to load the user
history dictionary back from the disk - native code is not affected
so there is no other point that may cause a problem.
In the practice, that means you'd need to have 129 words with a
common prefix (including empty string) but all different after
this. It's almost impossible with Google Keyboard since there are
only so many keys on the keyboard that you can make a word out
of, and then again you'd have to do it repeatedly until it
actually enters the user history dictionary, wait for it to get
saved on the disk.
The bad news is, if you manage to get this far, the keyboard will
crash every time and won't be able to get up until you clear
data for the package.
The good news is, the dictionary itself is not corrupted and only
the reading code is wrong. So updating to a newer version would
actually even recover from this situation.
All in all, considering how almost-impossible this is to trigger,
I don't think even a single user actually did hit this bug.
Bug: 8583091
Change-Id: Iabb2a7f47cbd9ed3193d2a3487318d280753e071
This uses the old suggestions. It does not try to recompute
new suggestions if there are no old suggestions yet: this is
coming in a later change.
If there are no suggestions, this shows the word itself
as a suggestion.
Bug: 8084810
Change-Id: I4c2e25df0ff3673be1825f57a0c19a9d23d47a48
Kurt Partridge
Jean Chalard
Tadashi G. Takaoka
Baligh Uddin
Ken Wakasa