IssueTracker

Appears to be same as Issue 36942235. According to that issue, this bug was introduced in SDK 14: "It looks like this is due to frameworks/base commit 14d0ca1473b991288b2dfab57"

[Comment deleted]

I thought it may have been fixed in 4.3, but tried it on my Galaxy Nexus 4.3, and I'm stilling experiencing it.

@jdko I do not think that this is the same bug as Issue 36942235. Moving to SDK version 15 fixes the problem here, while the bug in 26956 was introduced in SDK 14.

I have also experienced this bug on a Nexus 7 on Android 4.3.

how can something so simple not work?

I'm noticing this on a Nexus 4 running 4.3 even when the view is not an EditText. It appears OnKeyListener.onKey() is not being executed at all for KeyEvent.KEYCODE_DEL.

[Comment deleted]

This is probably a problem with the default soft keyboard (and not EditText).  The problem does not exist, for example, with a hard keyboard.  And the problem does exist for views other than an EditText.

The problem goes away if you set targetSdkLevel in your manifest to 15 or lower, even if your Project Build Target is at 17.

It has been reported here:

http://stackoverflow.com/questions/14560344/android-backspace-in-webview-baseinputconnection/14561345#14561345

that deleteSurroundingText() is called on the InputConnection object for the view that is receiving the soft keyboard input when the backspace key is tapped, even though a KEYCODE_DEL event is not being sent.  The above link has an interesting and apparently reasonable workaround for a WebView that could be adapted for other kinds of views, although it would have to be implemented on a view by view basis.

Just a little more information:  I've found that for a given view that is NOT an EditText, from the time you select the field a count appears to be maintained of how many letters have been typed, and you can use backspace to delete letters exactly that many times.  So if you type five letters to a field that is, say, handling the keystrokes itself, you can then delete exactly five times, but no more.  And if you switch focus away from that view and then come back to it, the number gets reset to zero and you cannot use backspace to delete at all even if letters have been typed when that view previously had the focus, until you type some new letters, and then you can only delete as many as you have typed since the view most recently received the focus.  Hope that helps in reproducing and debugging the problem.

This is still an issue in 4.4, changing the targetSdkLevel to 15 doesn't change anything

My code uses the NDK, target is 2.3.3 (10). With the release of KitKat 4.4 I received reports of the backspace key no longer working.
The report says, text which is inside an input field can not be deleted. Only newly added letters can be erased. Note: I am using my own UI system.

Logging the events (in NDK side), shows no more events for the backspace.

This is exactly what #9 posted above, there seems to be some internal counter which is blocking the backspace.

I find this unbelievable, how can anyone add such a feature to a working ecosystem.

Is this even the right place to report bugs, will google know about it?
They should do some sort of emergency fix or provide some workaround.

On iOS there was something similar, I had to feed garbage text into the system in order for the keyboard to report backspace! This was due to using a hidden text input field.

i have a similar problem using the onscreen keyboard to log into facebook on Galaxy S3 - none of the suggested workarounds here or elsewhere resolve the issue. (setting api levels, not using custom keyboards, resetting settings, entering text and being able to backspace that many times...)

this might be a mental suggestion but, maybe some QA testing is in order? many other software vendors are no better - MS and Apple frequently ship things which would never have made it through the most cursory of tests (although usually these are developer focused things like tools and samples).

Can Google staff please respond as to how NativeActivity based applications should receive keyboard events which include backspace?  Looks to me like we are seeing broken release after broken release, and this is coming at the cost of user experience.

See http://developer.android.com/reference/android/view/KeyEvent.html:

"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 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."

Looks like the breakage is deliberate.  Not at all clear to me how we are supposed to get text input in NativeActivity-based applications.

Hi,

The answer is quite simple. Applications should *never* rely on key events to manage user input. The reason for this is, it results in a very poor user experience.

To start with, there are too many cases where it does not work. It does not work appropriately for CJK languages. It does not work correctly with gesture input, or with voice input, or with toggle input, or any new inventive input method developers may come up with in the future. In fact, the only case where it works is for only restricted cases of the poorest input experience : a legacy hardware-keyboard-like input method, which is a poor fit for the mobile era.

This is why Android defines a rich API through which IMEs communicate to the applications. It is method agnostic and language agnostic, and all software input methods are implementing it. Applications are supposed to make use of this API, and using EditText is the simplest way of doing this (more on this below).

Please stop relying on legacy key events for text entry -- AT ALL. It is good to support them, but requiring them is bad for everyone. It breaks consistency, it locks some languages out of your app, and it forces users into a much poorer experience than they expect on Android. And as noted in comment #14, input methods are explicitly under no obligation at all to send key events, though some may choose to do it.


There are two simple ways of implementing the rich text input APIs. Both will require some of this is done in Java land.
The first one is to simply use EditText. If your app needs to do its own rendering, you can either subclass it if that suits you, or make it hidden while you render any changes to the text. You could also use DynamicLayout and Editable to achieve the same effect.
Another possibility is to implement directly the InputConnection API by extending BaseInputConnection, however this is a *LOT* of hard work and should generally only need to be done by applications that have very specific needs with regards to text edition, like an IDE or a word processor.

[Comment deleted]

I've developed a workaround for this issue, and for the related  issue 36949180 , for use by those apps that for the present continue to use TYPE_NULL behavior to trap key events.  

The presentation of this workaround describes the concerns that Jean has pointed out, while at the same time providing a way for apps that presently rely upon TYPE_NULL behavior to continue to access that behavior.  The discussion, including code, is posted here:

http://stackoverflow.com/questions/18581636/android-cannot-capture-backspace-delete-press-in-soft-keyboard/19980975#19980975

I would appreciate any comments regarding this workaround, as well as hearing about any results obtained if people use it, and also any improvements that might be made to it.

[Comment deleted]

Another work around that conforms to Android's design and doesn't rely on KeyEvents directly is to use an EditText with a TextWatcher.

When the text watcher fires, check if the EditText is empty. If so, prepend white space and move the cursor to the new position. This way the user can keep using the delete key to fire TextWatcher events.

The benefit to this solution is:
It won't violate foreign keyboard implementations.
It won't rely on KEYCODE_DEL to indicate when a delete is needed.
It won't distort auto features.

The downside:
Input hints and input types will be difficult to support

I am using an app that has this issue because of Android. Please fix it.

RichardG...@gmail.com

Can you provide your solution?

Maybe we could handle Keycode_del with using text wrapper, But when we need to handle for empty edittext, what should we do? There are a solution about this on Stackoverflow(http://stackoverflow.com/a/19980975/483988). But I need to open Number Keyboard, and I doesn't support it.

Nexus 5 with latest firmware still have this problem.
hey you guys please fix this.

our native game using GLES to render custom in-game text editor, but the initial text in the box cannot be deleted because the empty view cannot receive AKEYCODE_DEL.

#15(Project Member) makes a good point, but it needs Java and not native friendly, I hate this :(

our game uses in-game text edit control, it holds its own text buffer, rendering its own texts using API independent rendering interfaces, and simply receive key codes from platform specific app modules. it's supposed to be a cross platform solution and I believe lots of game UI libs do the same thing. now you're telling me that using key codes is not reliable, hey, you need to reconsider this.

all I gotta say is that you guys really need consider native developers' experience, seriously.
in the native end, a input message callback with UNICODE support is more direct, simple, and efficient, and more friendly to native developers. and it makes transplanting games from other platform much more easier.

for me its impossible to use TextEdit without modifying the mechanism of game edit control in native code. but the modification needs too much work.
Even use this approach, it will also break the portability in some way.

Now I'm trying using whole TextEdit instead of native in-game edit control, that seems much more easier. But I still wish this problem fixed soon.

#19 RichardG...@gmail.com

Thank you for your suggestion, it works beautifully.. or, it works :)

Nothing like invisible characters to work around Google's alternating design decisions.

Maybe is Google Keyboard' Issue. updating to the  latest version, KEYCODE_DEL event works :)

I have code event delete in EditText. But i don't get Event off keyboard KEYCODE_DEL on android API 22.

Having the same problem on API 25, is there any update to fix it?

This is intended behavior. However, this behavior breaks functionality with ReplacementSpan which relies on a KeyListener added to the underlying Spannable to work correctly. Specifically, ReplacementSpan should delete the entire span upon KEYCODE_DEL. Any KeyListeners added to the underlying text will not receive dispatch events from the soft input because Editor modifies the text directly with a "batch" modification.

Relevant class:
https://github.com/android/platform_frameworks_base/blob/master/core/java/android/widget/Editor.java#L1412

Help

Help with this issue