Double-backspace on lock screen

[GoogleCodeExporter]

Cyanogenmod 11 snapshot M10

What steps will reproduce the problem?
1. Enable password lock screen
2. Lock phone
3. Try to unlock -- type in any characters (not necessarily real password)
4. Press backspace to erase 1 last character

What is the expected behavior?
1 character erased

What do you see instead?
2 characters erased

What version of Hacker's Keyboard are you using, for example "1.37"? (See
"Debug" section at the bottom of the app's Settings menu.)
1.37.1419

On what phone or tablet?
Samsung Galaxy S3 (SGH-T999L)

If applicable, does this affect the 4-row or 5-row layout, or both? Which
language(s)?
4-row; english or dvorak (same behavior)

Please provide any additional information below.

This did not happen with earlier versions of Cyanogenmod, so it's likely a new 
"feature" or an upgrade bug

Original issue reported on code.google.com by fry....@gmail.com on 3 Oct 2014 at 12:49

[GoogleCodeExporter]

1.37.1419 samsung galaxy s4 mini 9195, english dvorak czech all of them 
2characters erased on both 5 and 4 row layout.

Original comment by matej.se...@gmail.com on 20 Mar 2015 at 1:11

[GoogleCodeExporter]

I can't reproduce this, I would suspect it's a bug in the Cyanogen version 
you're using, sorry.

Original comment by klausw@google.com on 6 Apr 2015 at 10:38

• Changed state: Invalid

[GoogleCodeExporter]

Reopening, I dug around a bit further. The upstream LatinIME has some 
relevant-looking code, Hacker's Keyboard doesn't currently have this workaround 
in place.

Adding an equivalent check will be a bit annoying since it involves 
asynchronously looking up the target application in PackageManager, with some 
care needed to handle caching and memory leaks.

I'll see if an easier workaround is possible, i.e. special-casing the 
lockscreen for now.

https://android.googlesource.com/platform/packages/inputmethods/LatinIME/+/maste
r/java/src/com/android/inputmethod/latin/utils/TargetPackageInfoGetterTask.java

                if (inputTransaction.mSettingsValues.isBeforeJellyBean() ||
                        inputTransaction.mSettingsValues.mInputAttributes.isTypeNull()) {
                    // There are two possible reasons to send a key event: either the field has
                    // type TYPE_NULL, in which case the keyboard should send events, or we are
                    // running in backward compatibility mode. Before Jelly bean, the keyboard
                    // would simulate a hardware keyboard event on pressing enter or delete. This
                    // is bad for many reasons (there are race conditions with commits) but some
                    // applications are relying on this behavior so we continue to support it for
                    // older apps, so we retain this behavior if the app has target SDK < JellyBean.
                    sendDownUpKeyEvent(KeyEvent.KEYCODE_DEL);
                    if (mDeleteCount > Constants.DELETE_ACCELERATE_AT) {
                        sendDownUpKeyEvent(KeyEvent.KEYCODE_DEL);
                    }
                } else {

Original comment by Klaus.We...@gmail.com on 23 Apr 2015 at 5:36

• Changed state: Accepted

[GoogleCodeExporter]

I just wanted to mention for the sake of completeness that the topic @

https://groups.google.com/forum/m/#!topic/hackerskeyboard/O1jQR-Wkt40

has some additional details re: more bug reports.

Original comment by TPSam...@gmail.com on 24 Apr 2015 at 2:20