Hackerskeyboard: 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 24 Apr 2015 at 2:20

[GoogleCodeExporter]

Link collection for reference:

https://github.com/android/platform_frameworks_base/blob/a6ed1b9547dcd592031a415
739cc7e672c068f7c/core/java/android/view/KeyEvent.java#L60
 * As soft input methods can use multiple and inventive ways of inputting text,
 * there is no guarantee that any key press on a soft keyboard will generate a key
 * event: this is left to the IME's discretion, and in fact sending such events is
 * discouraged.  You should never rely on receiving KeyEvents for any key on a soft
 * input method.  In particular, the default software keyboard will never send any
 * key event to any application targetting Jelly Bean or later, and will only send
 * events for some presses of the delete and return keys to applications targetting
 * Ice Cream Sandwich or earlier.  Be aware that other software input methods may
 * never send key events regardless of the version.  Consider using editor actions
 * like {@link android.view.inputmethod.EditorInfo#IME_ACTION_DONE} if you need
 * specific interaction with the software keyboard, as it gives more visibility to
 * the user as to how your application will react to key presses.

https://android.googlesource.com/platform/packages/inputmethods/LatinIME/+/maste
r/java/src/com/android/inputmethod/latin/settings/SettingsValues.java
    public boolean isBeforeJellyBean() {
        final AppWorkaroundsUtils appWorkaroundUtils
                = mAppWorkarounds.get(null, TIMEOUT_TO_GET_TARGET_PACKAGE);
        return null == appWorkaroundUtils ? false : appWorkaroundUtils.isBeforeJellyBean();
    }

https://android.googlesource.com/platform/packages/inputmethods/LatinIME/+/maste
r/java/src/com/android/inputmethod/compat/AppWorkaroundsUtils.java
    public boolean isBeforeJellyBean() {
        if (null == mPackageInfo || null == mPackageInfo.applicationInfo) {
            return false;
        }
        return mPackageInfo.applicationInfo.targetSdkVersion < VERSION_CODES.JELLY_BEAN;
    }

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

Original comment by [email protected] on 9 Jun 2015 at 6:18

[GoogleCodeExporter]

Hi I'm having this problem also. Pressing backspace once on lockscreen deletes 
2 characters.
Lockscreen type: Password
Language: English UK
Android 4.4.4
CM 11 20150512 NIGHTLY-I9305

Original comment by [email protected] on 28 Jul 2015 at 8:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

usb otg hardware keyboard also affected btw

Original comment by [email protected] on 31 Jul 2015 at 12:51

[guysoft]

Hey, this happens to me not only in the lock screen! LG G4. Is there a way I can help by giving logs or output?

[TPS]

@KlausW After #487, this is perhaps the most annoying bug left in HK.… Do you mind taking another run @ it? :bow:

[klausw]

@TPS I'll see what I can do, but based on the previous investigation this will be a bit tedious to fix. The code is getting old and creaky, it's forked off the Gingerbread AOSP keyboard from 2010, and Android has changed quite a bit since then. At some point backporting special cases risks destabilizing things even more.

@guysoft I think I know what the issue is, see the jan 22 comments above, so there isn't really a need for additional log files.