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
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
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
RichInputConnection#getWordRangeAtCursor may now returning
either a SpannableString or a String. We can't test that with
String#equals(), but TextUtils#equals() does the job for us.
Change-Id: I59ebe54207e92f4d90b49476b64f1e12fd4929cb
Yes that's even harder to understand. The old technique doesn't work
any more, so I have to drill a new hole in this class.
Bug: 8303100
Change-Id: I70a41b5094dab2bb56a17eaf55b2a2df853e4bb6
The test was not passing the correct input type when it was
creating the text view, resulting in mismatched types seen from
TextView and LatinIME with some bad results. The test would
even go as far as restoring it after it's been fixed by TextView.
Additionally, since we want to enter litteral carriage returns,
the input type should be MULTI_LINE. If not, TextView does
not allow carriage returns.
Bug: 8302690
Change-Id: I1c20bcf6ca554ad981048ec181e19c649f6c742e
The important bug is in findWordInTree. The problem, which is
not obvious, is that we were calling codePointAt() with the
code point index in the string, instead of the char index.
The other bug this change fixes was harmless in the practice,
because it's in the iteration which is only used for debug and
pretty printing purposes. It's very similar in that it would
substract a length in code point to a length in chars and
truncate a StringBuilder at that length, so it would fail in a
quite similar manner. This changes the meaning of the "length"
attribute in Position, but it's clearer this way anyway.
Bug: 8450145
Change-Id: If396f883a9e6449de39351553ba83f5be5bd30f0
