The only use of mDeleteCount is to implement delete
acceleration. It's reset at each non-delete code point, and
is guarded by a timer.
Plus, ultimately we want to remove this completely :
acceleration should be implemented by actually deleting
stuff faster, not by deleting several code points at a time.
Change-Id: Ia3144860b3aa2499034f2a2a7c81f32087af9598
We don't support LOG_FULL_TEXTVIEW_CONTENTS any more, nor do
we have any plans to support it again in the future.
This also is a prelude to removing mIsExpectingUpdateSelection.
Bug: 11226045
Change-Id: Ib68c6daf52993b87225a7ea9e71a414caaecfdb7
cherripick of I9c6a948331726a821bd3ccec9c1d02dec2c4703a
(forward cherrypicking this because the automerger is stuck now.)
This bug was leading to corrupted rendering of surrogate pairs in the following
scenario.
1. Type some emojis
2. Move the cursor at the beginning of the text field
3. Hit backspace even though there's nothing to delete
4. Move the cursor after some emoji
5. Hit backspace
The root cause of this issue was the out-of-sync mExpectingUpdateSelection if
handleBackspace() gets called when the cursor reaches at the beginning of the
TextView. In such case, mExpectingUpdateSelection shouldn't be set true because
there's nothing to delete, so there will be no onUpdateSelection() calls associated
with it. Due to this bug, the cache in RichInputConnection could get stale at step 4
described above. Then the following handleBackspace() that should delete a surrogate
pair was not working correctly because of the stale cache.
bug: 11181913
Change-Id: I1cbf444d8d105416e7de75c16d80b3797f470495
This is not useful because we're going to call setSelection again
with different values on the connection right away.
Also a preliminary change for
Bug: 10792236
Change-Id: I46c6ef1fbb3624086099bf81afddb0ef5ae85661
Since loadKeyboard relies on the input connection being
available to give it the auto-caps state, but also can't
be called twice in a row because it needs to save and
restore its state and invalidates it after the restore,
we need to wait until we know we have a valid input
connection to call it.
Bug: 11107229
Change-Id: I1c7baf3215682df6f6ceb357bd37254f9e7418c7
This also includes a fix that allows this code to read surrogate
pairs in this processing.
Bug: 11070482
Change-Id: If5ef8d6863938252f09128b7e99ea07ece6e7019
What's happening here is, setAlphabetKeyboard sets the
keyboard to AUTOMATIC_SHIFTED and updates the keyboard, then
restoring the keyboard old state sets it back to UNSHIFTED without
updating it. When we finally know what the correct value is,
we try to set it to UNSHIFTED, but since that's already the currently
recorded state, it skips updating the keyboard forever.
The solution is to avoid setting the shift state without updating the
keyboard.
Bug: 10948582
Change-Id: Ic8670401e378f8284e851281f91a9ad93eac8e90
This is not enough to really fix behavior with TYPE_NULL,
but it does make things a bit better.
Bug: 10949594
Change-Id: Ia359f781cdd76a2e2c5a4c9f166025d81b931174
