New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 118639 link

Starred by 176 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: WontFix
Closed: Aug 2014
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Compat

issue 301801

Sign in to add a comment

keydown and keyup events do not have proper keyCode (it's always 0)

Reported by, Mar 16 2012

Issue description

Chrome Version: Chrome Beta for Android
Application Version (from "Chrome Settings > About Chrome"): 0.16.4301.233
URLs (if applicable):

From "Android Settings > About Phone/Tablet"
Build number: IML74K
Device: LG-P999

Behavior in Android Browser (if applicable): keydown and keyup events produce proper keycodes (a produces 65, for example).

Steps to reproduce:
1. Load the attached HTML file in Chrome for Android.
2. Click on the input element.
3. Press any key.  It will always show a keyCode of 0.

Expected result:
The keydown event should produce a proper keyCode.  For example, pressing 'a' should produce 65.

Actual result:
keyCode is always 0.  In my testing the only key that seems to produce a keyCode other than 0 is the backspace/delete key (keyCode 8).
558 bytes View Download
Showing comments 207 - 306 of 306 Older

Comment 207 by Deleted ...@, Nov 10 2014

Android 4.4.4. Issue not resolved:

event.which always returning 0, event.preventdefault not working and more
It's not an Android thing.  It's chrome v38 and above.  preventdefault is not yet fixed in any version.
HEADS UP:  Due to problems with multi-to-single character composition on keyboards other than English, keycode generation had to be changed from always-on to manually-enabled.

To make keycode generation work for your inputs, add the attribute "autocomplete=off".  Without it, you'll get "compose" events (229) instead of proper keycodes.

What about ContentEditables?
It should be fine just by adding that attribute.

Comment 212 by Deleted ...@, Mar 10 2015

I too hit this problem developing a phone gap app. I was unable to get any difference by turning off autocomplete.

However my project leverages angular 1.2 and very fortunately I was able to pull and detect changes in an input field with type="number" using a directive that set a keyup listener on the element.

I can get a key by key diff on the field by inspecting the $viewValue on the control - hope this helps someone out there!

    link: function (scope, element, attrs, control) {
           // listen for key ups on the element
           element.bind("keyup", function (evtObj) {
                    // pull DOM value to work on - angular nabbed the correct viewValue for us, WOOT!
                    var charsval = control.$viewValue.toString();

cordova -version
phonegap -version

Status: WontFix
Sorry y'all, but I have bad news.  This is being reverted for the upcoming stable branch.  Too many non-western-keyboard use-cases depend on having "compose" key-codes instead of guessed "proper" ones.  We've tried fixes that compromise but they never get all the edge-cases.

The bottom line is that if you want your keyboard-knowledgeable web page to work with Chrome, you're going to have to be tolerant of IME's idiosyncrasies with regard to key-codes.

I'm disappointed by this, too.  It was a lot of effort to work this out and I'm sorry to see it reverted.

Just wanted everybody to know in advance and provide the reasons why.
Ugh.  Well, are there plans to support KeyboardEvent.key (  That would probably allow me to work around the problem at least.  The real problem keys are the specials like backspace, shift, enter, delete, etc.  For KeyboardEvent.key those have hard-coded values that should be the same no matter what language or layout you're using.

For all other keystrokes I can just capture the output of the IME.
Hi, I just need to point out that Firefox Android does not exhibit any of the flaws you mention:


I am not able to see the last one (403 Forbidden)

Yet, they are able to correctly send key codes when the classic keyboards are used. When I am using the japanese keyboard, they don't seem to send any keycodes, while I am composing. They still are sending "regular" keycodes when pressing enter for instance.

I tried to look for some hints on how they do it in the Firefox code (which I don't know at all), but I did not seem to find anything mobile specific. Apparently they just request a flat Android EditText object (

Is it something like this adaptable to Chrome(ium) ?
#214, 'key' has been discussed in  Issue 227231 .  However, the real problem is that there is no technical reason for a software keyboard in mobile to behave like a traditional physical keyboard.  See the post from Kenji in #107.

I understand that your applications rely on some key events like backspace, shift, enter, delete, etc, but did you make sure that you would be able to receive those events if your apps were Android native apps?  I doubt it.
It's not an android app! It's a webapp that must run on Chrome, Firefox,
IE, Safari, Opera, etc!
Em 15/04/2015 18:25, <> escreveu:
This change is not backwards compatible; it was not communicated beforehand and there is no way to opt-out. Additionally, workarounds and new approaches that work across active browsers have not been well communicated.

As a result of this change my own app and many others completely stopped working in important ways that affected our users.

The change breaks existing web pages using key events that may have been written before Android even existed. This seems to go against the philosophy that has typically governed web development. Backwards compatibility should not be given up without good reason.

While sending key events is not possible for many new soft keyboards, that doesn’t mean it has to be impossible for every keyboard. The browser is a platform for developers, and developers have written and will continue to want to write applications including uses cases that require interacting with the keyboard one key at a time. There ARE use cases for a traditional keyboard that simply mimics a hardware keyboard. As long as hardware keyboards exist people are going to want key codes.

There should be a way to get the the traditional behavior by requesting a traditional keyboard (with the option of disabling autocorrect / suggestions).

1) Don’t break backwards compatibility, at least not without an escape hatch.

2) Key events with key codes are still a useful paradigm for some use cases and there should be a way to keep that behavior.

3) If you are going to break it, tell us what to do instead (clearly).

Thank you for your effort on this and the interest and concern that you have already demonstrated.
Hi Yukawa,

What we would like as developers is at the very least a coherent explanation for the revert.

You mention bugs, but as I pointed out, other browsers (namely FF and Safari iOS) do it the correct way, without the bugs.
Your implementation has bugs, fine, then fix them, but both having keycodes and doing composition right are NOT incompatible.

Also I would like to mention that Chrome on Desktop (I'm using Chromium on ubuntu with Anthy to see the composition text) has done it the correct way. It sends 229 when composing. Correct keycodes when actually typing keys.
The argument internally to get this issue fixed could be to be at least on par with the desktop, which do get composition too ! Don't tell us that softkeyboards are special, it is not true.

I am sorry to say that your approach so far seems close to "Clicking on a tablet is not valid, because you now have touch events, do let's ditch all click events on mobile".
This is NOT the correct approach and you know it.

Lastly, I would like to mention, that you are also probably experiencing troubles with Android keyboards implementations (most notably the Google US one) which is not sending keycodes. This is really strange since the Google Japanese Keyboard does, and Swiftkey does.

If the keyboards are not sending keycodes I can see why it's extremely hard for chromium to handle it, it's probably best to just file a bug for given keyboard and not handle it.

I would like to I add that the only reason I take time for this bug, is not because of my users, which are using Firefox right now, but because I do love Chrome which is an awesome product, and I would like to be able to recommend it.

You can't compare FireFox and Safari to Chrome because the internals are very different.  Internally, Chrome depends on composition codes (instead of real key codes) to operate properly during composition.  It would require some significant changes inside Chrome to adapt to the change.  It's not impossible, but it's certainly not trivial.

> they are able to correctly send key codes when the classic keyboards are used

This is because the keyboards actually have physical keys and the OS sends the expected key events.  It's Android *soft* keyboards that do not (many, anyway), sending only composition events.  We tried to make an educated guess where possible but, well... see the first paragraph.

Composition events occur even on desktop, as has been mentioned.  This means that web sites need to handle them anyway in order to be fully compatible.

I still believe it would be great to support this.  Instead of analogies and comparisons to other products, how about providing distinct use-cases that are impossible without this?  What real products are not possible because of this deficiency?
As I mentioned, I really can see why educated guess can get quite tricky.
As you mention, it should be the OS responsibility to handle input.
I tried to look into chromium code for reasons on why you reimplement input, but could not find anything, are there any specific reasons ? It might help us understand why it's harder to support this.

> This is because the keyboards actually have physical keys and the OS sends the expected key events. 
> It's Android *soft* keyboards that do not (many, anyway), sending only composition events.  We tried
> to make an educated guess where possible but, well... see the first paragraph.

If I read this correctly, it would be possible to send correct keycodes if the keyboard properly sends them. I think that would be the saner way for everyone to handle things.  

When you say many Android keyboards don't send keycodes it, what is your frame of reference ?
Isn't it possible to have correct key codes at least on the Google keyboards and go from there ?
It seems not providing keycodes on a keyboard where it makes sense would be a keyboard bug, not a Chrome one.

Our use case uses heavily Mathquill ( which basically reimplements input for math. Keycodes are a natural choice as math is usually written with ascii symbols.
I looked into patching for composition event when I first met this bug, but honestly browser compatibility was not that great, and for a developer there are lots of hoops to make it work (or there was at the time). Keycodes work almost everywhere.
Anything I missed that might make patching for compositionevent easy ?

The Android IME system is *not* designed to have software IMEs send key codes and it's *not* considered a bug in a keyboard if it doesn't send key codes. Soft keyboards are perfectly within their rights to never send any key codes at all. Only hardware keyboards are expected to send them.
Nicolas, I certainly understand where you're coming from -- it's a discussion we've had internally many times.  The Android Keyboard team, however, has decided that key-codes are *not* the way to go... and I cannot say they are wrong.

While there are certain advantages to key-codes, they are also very limiting.  They get in the way of auto-correct, auto-suggest, swiping, voice dictation, and many others.  There are many possible capabilities of a soft "input method" that do not fit the paradigm of key codes.

While we try to make mobile Chrome support desktop Web on a mobile device, there are limitations and sometimes the better choice is to make mobile Chrome first support the mobile device and push desktop Web to second.

We understand that developers are essential to the Web (and Chrome) but if the choices we make create a jarring experience for our users (e.g. auto-whatever isn't functional, swiping doesn't work, etc.) then they won't use mobile web and *everybody* loses.

Regarding your specific use-case...  There are ways in Android to put the keyboard into "raw" mode where all advanced features are turned off and key-codes appear.  That would be sufficient, no?  I'll have to check how that is set within a web page.
Thank your for the constructive answer.

I do get that keycodes are limited in lots of respects and why they are not enough in some cases. 
My point was only to have some legacy support.

A "raw" mode definitely would work. I actually never expected anything more.
Something like autocomplete="off" or <input type="password"> do.

The bug as it was in 2012 however did not work no matter how (keycodes were always 0), which is why the potential revert was a real let down.

Comment 225 by Deleted ...@, May 3 2015

Hi all,

I'm using Cordova 3.6.4 in Visual Studio 2013 Community Update 4 to build an apps with a "chat" functionality, the main reason that I use this technology is because I want to, hopefully, write once and can use it in all platforms such as android phones, iphones, all mobile phone browsers, all desktop browsers.

In order to let the users inputting the "message" to be sent, I create a [div] which is contenteditable="true" at the bottom left of the html, at the right hand side of this [div], I have two [image buttons], one is the [happy face] button, the other is the [send button].  (You know, just like Whatsapp, Line and WeChat!)

At any time the user can click the [happy face] button to select one of the many "face image" to insert into the cursor at the [div], then I'll add the html codes into the [div], e.g. div.innerHTML += '<img src="1.jpg">'

So, the innerHTML of this [div] can contain characters AND images, e.g.

12<img src="1.jpg" />34<img src="2.jpg" />

Of course, the actual display is:

12[1st Picture]34[2nd Picture]

If the cursor is at the end of this [div], and I clicked the [BACKSPACE], I expect the [2nd Picture] will be removed, if I clicked the [BACKSPACE] again, I expect the letter [4] will be removed from the [div], this is work at ALMOST every platform I mentioned including all mobile browsers in android and iphone/ipad, all desktop browsers.  But IT DOES NOT WORK when I build an android apps and run it in ANY android phone.

Running it as a WebView in android phone, when I click the the [BACKSPACE], the letter [4] is removed instead of the [2nd Picture], when I click the [BACKSPACE] again, the letter[3] is removed.  I can NEVER remove the 2 images no matter which IME I'm using.

To work around, I tried to add a keyup/keydown/keypress listener to the [BACKSPACE} but it never fires.

At last, to work around this [BUG], I need to add a third [X] image button and use javascript string.replace to remove the <img> tag when users click this [X] button, but it looks very stupid to the users!

It makes me crazy that ALL IMEs do not remove the image for me by pressing the [BACKSPACE], and if the key events are not fired, I cannot remove the images myself!!!

What should I do?

Please help! Thanks in advance!

There are some issues with having IME deal with embedded objects.  Typically the IME gets U+FFFC (obj) character in place of the holder which makes it look like a single character that can be deleted.  This may be related to  Issue #466755  or it could be completely different.

Either way, it's IME's inability to delete the image within a WebView that is the problem that needs to be addressed.  If you have a test page that can be opened in a WebView that reproduces the problem, please create a new issue with those details and we'll look into it.

Comment 227 by Deleted ...@, May 8 2015

Thanks for your response #226.

The test page would be simple:

<div contenteditable="true">
12<img src="1.jpg">34<img src="2.jpg">

If the above html file is opened using a browser, everything is ok.  However, use any android app that has a webview and can open the above html, then, place the cursor at the end of the div (the software keyboard should be opened automatically), then press BACKSPACE.

Expected result: the image 2.jpg is removed.

Actual result: letter "4" is removed.  AND, there is NO WAY to remove images 1.jpg and 2.jpg.

I cannot ask the developers of those IMEs: pls. remove the images for me when my users click the BACKSPACE key!

So if the IMEs have problems, I expect I can "listen" to this "BACKSPACE" event and remove the images myself, but this event never fires!

Is there any work around for the time being?

Many thanks for your quick response!

lichiukenneth, please create a new issue with all the associated details.  Make sure it includes the label "Cr-UI-Input-Text-IME".  Thanks.
Labels: Hotlist-Input-Dev
Forgive my ignorance (I don't know much about the complexities here), but to what extent do the new DOM3 'key' and 'code' properties help here?  If we ship those consistently for desktop and Android ( issue 227231 ) does that address the scenarios where keyCode=0 is a problem?  Since 'keyCode' is now considered 'legacy' I'm loathe to invest a ton there, but I do think we should be investing more in the new DOM UIEvent APIs including high interoperability between browsers and consistency across platforms.

Comment 230 by, Jul 24 2015

Re #229: In principle |key| is the replacement for |keyCode| for most applications, though some specialist apps will likely want to use |code| instead, for layout/modifier/lock-state independence in certain situations.

If we can get to a state of having working |key| and |code| and find that |keyCode| is still important for older content then it should be possible to construct a shim that will generate |keyCode| that will work correctly for most keys.

Some of the uses for keydown/keyup/keypress on this thread sound more like workarounds of other brokenness in the platform (whether due to implementation or issues w/ the standard), so those may also be worth looking at.
 Issue 397472  has been merged into this issue.
 Issue 324458  has been merged into this issue.
Any new updated ? Still facing the problem on Android 4.4.4 and Chrome (latest version). I've tried Chrome version 37.0.2062 bu still same case (event.keyCode,event.which returning 0 and 229).The testing is done on the KeyDown of a contentEditable div
Any help would be appreciated,the case is critical
The simple answer is: It's not going to happen.  I tried several times using different concepts, and each introduces a set of problems that is "bigger" than than this issue.

If you're thinking in terms of key-codes on a mobile platform, you're limiting yourself.  Mobile does swipes and voice-transcription and who knows what other kinds of input.  Any attempt to rely upon key-codes is going to alienate some subset of your users.
Not going to happen? Not good. Why don't you pass the issue off to someone else? I'm going to have to write extra code just for android chrome because of this wholly unexpected behavior it exhibits.
I tried to get this working for a long time after it had generally been agreed that it was not going to work out well no matter how it was implemented.  I held out hope because it seemed a good thing to do it at all feasible.  I was eventually forced to agree that it is not.

Comment 238 by, Feb 24 2016

Recently, in Android Chrome, pressing Enter on the soft keyboard in a <textarea> has gone from sending keyCode 13 to sending keyCode 229.

This seems related, but it only started happening a few weeks ago so I'm wondering what changed.

I also don't really understand the explanation given for why this is so difficult to solve. One explanation given:

> They get in the way of auto-correct, auto-suggest, swiping, voice dictation, and many others.  There are many possible capabilities of a soft "input method" that do not fit the paradigm of key codes.

I understand that many things don't fit the paradigm of key codes, but I don't understand why that affects your ability to send a keyCode when something does.

> I tried several times using different concepts, and each introduces a set of problems that is "bigger" than than this issue.

Could you name the exact concepts and set of problems involved? It might also help save work from the next person who tries to solve this issue.
> I understand that many things don't fit the paradigm of key codes, but
> I don't understand why that affects your ability to send a keyCode when
> something does.

If the input device sends key-codes then Chrome will pass those along but the Google Android on-screen keyboard does NOT send key-codes.  There are other keyboards that do such as the "hacker's keyboard". Physical Bluetooth keyboards also send key-codes.

Not sending key-codes is a purposeful choice by the Android Keyboard Team because it frees them to expand on the capabilities of the keyboard without being limited to the desktops-with-physical-keyboards paradigm.

There is no compromise that is good for the end users.  Assuming the soft keyboard generated key-codes for individual presses like a physical keyboard, users would run into intermittent problems where it only works when they do some things.  The first time they swipe a word, it fails.  The first time they do voice dictation, it fails.  And then they'll complain that Android only works some of the time, never know when or where, and just be basically frustrated with the experience.

It's hard for us developers, I'll grant you that, but we need to adapt to the new world instead of trying to adapt it to us.
Can't you give developers an option to force a "dumb" keyboard to be used?  In specific situations it would be nice to have the option instead of having this functionality completely taken away.  Give developers freedom to opt out of the fancy keyboards if they need to.
Thousands and thousands of developers all over the world wait until you fix this bug, because they want to forget it.
The world and olympics champions have changed many times while Android Keybord Team still think that the world don't needs "desktops-with-physical-keyboards paradigm".
And you just can say "adapt to the new world"?

Physical keyboards are enabled by hundred years. It's absurdly to think that you can create a new useful behavior of the keyboard. You can invent new input devices/modules/plugins, but it will be another story. 60 years old keyboard behavior must not be broken. If user press some key - just let developers know which.

I think you just have broken some laws of robotics. Really. Code wins you. 

P.S. I just think guys that you have architecture problems with keyboard.

No. Applications cannot really control the choice of IME on Android. Which IME to use is entirely a user decision. Most devices don't even *have* a "dumb" keyboard - the standard Google keyboard doesn't have a mode that generates keycodes at all.
> Can't you give developers an option to force a "dumb" keyboard to be used?
> In specific situations it would be nice to have the option instead of
> having this functionality completely taken away.

But YOU are asking to take functionality away in certain situations.  You're just asking to take it away from the user (e.g. functionality to swipe or dictate) rather than take it away from the developer.

I understand what you want but it's not up to Chrome. I tried work-arounds but they all fail in some respect.  You're going to have to take this up with the Android group as they control the keyboard.

But consider this first:  If asking your users to install and use the "hacker's keyboard" is a problem for some users then asking them to *not* use swipe or voice dictation or whatever else will also be a problem for some users.

front.end can talk about physical keyboards being around for a hundred years but there's a good chance there are more soft keyboards in the world today than physical ones, possibly more than have ever been built.

Times *have* changed.  The only viable option is to adapt.
I agree that we can't force users to use dumb keyboards. But the classic Google default android keyboard does have keys !

SwiftKey, which is not a dumb keyboard, can manage sending keycodes properly when it makes sense (for instance when I hit a key, and not when I swipe or input in Kanji)

If they can do it, why can't you ? There are probably good reasons, but so far we fail to see them. Please enlighten us.

Also, if this bug needs to be duplicated on a Android Keyboard issues board please tell us where we can do so, I would be happy to switch the conversation to more appropriate people. As you mentioned, this is more a keyboard bug that a chromium one.

I agree that we can't force users to use dumb keyboards. But the classic Google default android keyboard does have keys !

SwiftKey, which is not a dumb keyboard, can manage sending keycodes properly when it makes sense (for instance when I hit a key, and not when I swipe or input in Kanji)

If they can do it, why can't you ? There are probably good reasons, but so far we fail to see them. Please enlighten us.

Also, if this bug needs to be duplicated on a Android Keyboard issues board please tell us where we can do so, I would be happy to switch the conversation to more appropriate people. As you mentioned, this is more a keyboard bug that a chromium one.

Yes, it was a choice by the Android Keyboard team for reasons I've explained.  They _could_, as you say, but choose not to.  They want to force developers to adapt to how users interact with their devices, not the other way around.

What they don't want is users being told, "Sorry, can't swipe here. Press each key." because that is a discontinuity and in breaks the experience as a whole and users complain, "Why doesn't it _just_work_?!?".

You're free to disagree with this but you should at least understand their point of view.

I managed to work around this for the most part because it does detect the 'enter' key and I jiggered something up to make the enter key act like the 'tab' key. Most of my other keydown code was moved to the 'input' event. The only thing I can't do so far is detect the backspace key, but I can rig up a 'swipe to delete' kind of functionality to replace that. So my fires are not burning too brightly with regards to this issue at present. Nevertheless, I still don't see why this issue can't be solved at some point.
Argh, Zare...@gmail was right, Textarea fires 229 when enter is pressed right now.
This issue is urgent for me as well. I have a few arguments to make about the UX for soft keyboards not sending keycodes.

> Yes, it was a choice by the Android Keyboard team for reasons I've explained.
> They _could_, as you say, but choose not to.  They want to force developers to 
> adapt to how users interact with their devices, not the other way around.

Chrome and other browsers can disable swipe for textfields by setting autocomplete="false" as detailed by the W3 specifications:

This is an urgent issue as some versions of Android triggers an the same keycode (229) for enter key when pressing Shift. This causes really bad UX, extremely buggy behavior. There are currently no work around that I'm aware of that solves this for me.

> What they don't want is users being told, "Sorry, can't swipe here. Press
> each key." because that is a discontinuity and in breaks the experience as a
> whole and users complain, "Why doesn't it _just_work_?!?".

You cannot force developers to write bad apps. Bad developers will still write bad apps with bad UX, same as how style codes cannot force bad programmers from writing bad code. I think the Android keyboard team is focusing too much on purist view instead of the more pragmatic approach on this issue, just my opinion.
> There is no compromise that is good for the end users.

The compromise was to send at least the identifiable key-codes for control keys like backspace, enter, etc. Right now every existing wysiwyg editor has unfixable bugs in chrome.
 Issue 615368  has been merged into this issue.
 Issue 593728  has been merged into this issue.

Comment 256 by, Jun 9 2016

I will not here that this leaves plugins like Selectize terribly broken for Chrome Android on a dumb keyboard: 

Comment 258 by, Jul 24 2016

>> This bug is also causing trouble for my mobile web app which uses bluetooth barcode scanners. We normally attach a keydown listener to the body tag to capture all keyboard input and look for barcodes with a regex. But it's always 0

I also hit this bug with the same reason, as a workaround, we told our users to  use Firefox Android instead.

Comment 259 by, Aug 2 2016

These problems still seem to be plaguing browsers on Android devices. Keypress events are not firing at all, and keydown/up events are returning incorrect characters, whether using keycode or charcode. The only choice I see is to switch to input event, but the goal of keypress is to get the character before its committed to the inputValue, then I can validate and allow or prevent default. Now I have to do more lifting to back out existing input values if it's invalid, and then ensure all input value changes are still being handled wherever they've been applied. 

Comment 260 by, Nov 17 2016

> Right now every existing wysiwyg editor has unfixable bugs in chrome.

I want to second this. I'm working on a code editor (CodeMirror, as used in Chrome devtools) and a rich text editor (ProseMirror) which use the contenteditable feature. Both need custom, configurable behavior for when the user presses backspace at the start of a paragraph/line, and in the current Andoid Chrome, that part is broken.

I am not married to key events, I don't even necessarily need to be able to prevent the default behavior (I can patch things up after the fact), but I do need _some_ way to figure out when backspace was pressed, so that I can perform my custom backspace-specific logic.
It's not really a Chrome thing.  Google's soft keyboard does not send key codes.  Attempts to programmatically determine what the key codes might have been all end up breaking something else.

You can try taking this up with the Google Keyboard team but they'll tell you what they told us:  Keyboards are the way of the past with mobile devices.  Don't expect them for input.

Note that if you use a physical keyboard on an Android device, then you will get the codes.  Same with some other soft keyboards, like the Hacker's Keyboard.
Have you tried listening to input and beforeinput events. They are available behind a flag and tell you the deletion mechanism. 



Feedback on this pending API is appreciated even though we haven't shipped it yet. 

For reference, you can work around this bug in some cases using composition events: compositionstart, compositionupdate, and compositionend.  For example, if you were using my HumanInput library ( you could trigger a function whenever any input element on the page is changed (e.g. the user types a key in their software keyboard):

var HI = new HumanInput();
HI.on('compositionupdate', function(event, whatWasTyped) { console.log("User typed: " + whatWasTyped); });

That would log "Abc" if the user typed those characters on their software keyboard.  You can detect the backspace character by checking the length (if it's -1 from previously then the backspace key was pressed).

If you only care about when the user is *done* typing something (or they press the enter key) you can use compositionend:

HI.on('compositionend', function(event, whatWasTyped) { console.log("User typed: " + whatWasTyped); });

These two events should make it possible to detect regular character input at least (still no good for modifiers like Shift or specials like ESC).  Probably good enough for barcode scanners (just make sure your input element has focus).  You can also perform some trickery by having an invisible <input> element always regaining focus after mouseup or keyup.  That way all new input can be detected this way *in addition* to regular keystroke handling.

Note: The 'input' and 'beforeinput' events don't provide enough information to actually work around this issue.
To some extent I understand that emitting keyCode does not makes sense since the word is not yet committed, but I have a confusion that same should be the case with safari on iOS. There it can capture keyCode on every keyup event. Why and how are they doing so?

Any answer pls ??
Key codes are a feature of the keyboard, not the app.  There are soft keyboards for Android (e.g. the "hackers" keyboard) that always emit codes but the official Google keyboard does not for all the reasons discussed above.

Comment 266 Deleted

same problem here, need to access keycode to change the position of the cursor. please fix it.
Patrick, please see earlier comments (#264 being the most immediately relevant) on why it will not happen.

"I think the Android keyboard team is focusing too much on purist view instead of the more pragmatic approach"

So it's too hard for engineers to figure out, or just like an engineer's pride thing? I submit to the team: the customer is always right. Can we swallow the pride and Just Make It Work? This single issue has had multiple of my customers switch to using iOS. I prefer Android, but barcode scanning and other key-based activity that doesn't work in Android/Chrome works in every other browser we support.
raymoro@ You haven't indicated why you cannot handle the other types of events (input, composition, etc) in your javascript. It should be relatively easy to handle. 

keydown, keyup, keypress are related to physical key events. There is no physical keyboard on Android unless you plug in a physical keyboard via the USB port. If you do that then you will get keyboard events. 

It sounds like you are narrowly focusing your opinion on Latin1 language systems and there are many more languages that produce characters in a sequence that cannot be mapped to physical key presses on an imaginary keyboard. We are trying to be consistent that key events are hardware based events. The logical layer above that is composition events which encompass all writing systems.

It's not necessarily "cannot handle" but generally "will not" create one-off hacks when better solutions exist (iOS/Safari, and all the desktop browsers, for example).

Narrow focus: absolutely. The focus is based on the hardware and the audience. Programming is only one "narrow" facet of the problem, but believe-it-or-not not all companies are Google-scale and are prepared to staff call centers for multi-language support, multi-language docs, customer care, services, and content authors and therefore operate only in a "narrow" band of locales and languages. I believe this is fairly common hence the various comments in this thread, and perhaps the reason this bug report exists.

Thank you for the suggestion - I will pass that to the team. Can input and composition events block ranges of characters from being input in the first place the way that keydown can? For input masks, for example?
The purist decision has been made for us by the Android keyboard apps a long time ago.  It's not within Chromium's power to Just Make It Work, 
not without serious compromises.  At most we could fake keyboard events from the composition events, but it's strictly better to cleanly passthrough the composition events fully to JS and let the JS implement their own faking, which can then take application-specific needs into account.

> Can input and composition events block ranges of characters from being input in the first place the way that keydown can?

No, input and composition events are not cancelable, because Android keyboard apps don't expect this and may react buggily.  If needed, I recommend you delete the character(s) that was input in your JS in reaction to the "input" event.

> barcode scanning

If your barcode scanner sends physical keyboard-style events, Chrome for Android ought to send keydown/keyup.  It's possible there's a separate bug here unrelated to the core issue that we might investigate, for example we currently have filed about a scanner usecase, might that be your problem?

Comment 273 Deleted

<div contenteditable="true">
12<img src="1.jpg">34<img src="2.jpg">
Similar to comment 227,
When a space key is pressed, text prediction keyboard app will remove all the <img> within the contenteditable's innerHtml. I was trying to listen to space key and do something to prevent text prediction.
Is there any way around this?

Thank you!
Well great to see the andriod ux preserved. I have an app with a wysiwyg editor, that only exposes key events. My users are able to type @ and have a nice employee mention feature, that spawns an ajax backed element to select fellow employees. After serverside provides some processing the mentionee can recieve an email or in app notification. 

Its crucial i support desktop and mobile devices for best interests of my 80k odd user base.

I pointed my team to this thread.

We managed to adapt, 

We added a button on the toolbar triggered by UA string check for chrome android, updated call centre scripts, internal comms etc.

Pass on my thanks to the keyboard team, the web community enjoys browser wars when vendors defend their ux innovation ideas.

And special thanks for the feature detection on the navigator once the wont fix was established.

My users will appreciate the discontinous experience as they move from device to device.

All the best from my team to yours.

Issue 805239 has been merged into this issue.
My question to Chrome team - can we implemented own keyboard for such occasions?
It does seem possible to write your own on-screen keyboard for Android so that tapping each key produces a key event instead of inputting text through IME commands (users would then have to select your keyboard to use your site properly). Or, you could build a keyboard UI in JavaScript and do whatever you want when each key is pressed. I don’t know if either of these is the best solution for your use case, but they seem possible.
 Issue 409664  has been merged into this issue.
You don't even have to write your own -- there already exist soft keyboards that create key up/down events.  "The Hackers Keyboard" is one.

About "the hackers keyboard" I didn't know (thx), unfortunately my comment to the whole situation (it's nothing personal) is: the most popular platform doesn't support some apps, because few teams from one company can't find agreement. 

I could write own keyboard, I could even write own OS or make device (this is not irony or inpolite comment), but it's not case and I think, that one of biggest company on the world really has resources to resolve it in "default" Android taste.
If by "most popular platform", you mean Chrome, it's not a Chrome thing.

If you mean Android, it's a deliberate choice by the Android Keyboard team and they have made that choice for good and considered reasons.  It's true that there are some issues with the choice but there are good things, too, namely that it encourages developers to not rely on a "feature" that does not apply swiping, voice dictation, and other alternative input methods.

So while it may be that some apps are not supported, the alternative would be some users not supported.  Developers have many incentives and options to do things in other ways.  Users have fewer.
bcwhite@, thank you for your comment, which is interesting.

Please note, that I have seen info about "good and considered reasons" many times about many people and companies. I believe, that it was case for many Microsoft, VW, Samsung, Apple and others actions, unfortunately thx to these "good and considered reasons" users were loosing something.

We have this bug, we have, we have and maybe others. It's about Chrome+GBoard.

If something cannot be resolved, can we at least get official documents about it, how to make workarounds?

Or can we get API update in next Androids, which will allow inform keyboard if it should produce these events or not? If application ask for keyCode, it will be enabled; done

There are also many other ways to resolve it, it's just question, if somebody want or not to do it.
two more words: I'm reading, that MS added resuming downloads in Windows Update. 

Do we really want to have the same with keyboard features? Or are they really so obsolete that we want to remove them now?
come on guys at least implement .key property with the value that is send to the input field. I mean I got a web app that works just fine in Safari which is also WebKit but not on my latest Android phone. I really don't understand how such a basic functionality can be missing from Chrome for over 4 years now.
I assume you mean Safari on an iPhone.

To be clear:  It's not Chrome!

If you connect a physical/bluetooth keyboard to Android or use a soft keyboard like the "hacker's keyboard" then you'll find that Chrome gets and processes keycodes just fine.  The issue you're having is that the default Android Keyboard does not generate keycodes.

And this is intentional!  Keycodes are limited to hunt-and-peck typing.  They don't work with "swipe" gestures, voice dictation, word correction, or any of the many variation on "input" supported by mobile devices.  If you're relying on keycodes, you're going to frustrate (if not simply exclude) a significant (and growing) number of users.
ok thanks for clarifying and pointing out the edge cases, but isn't that a bit overthought? I would fire keypress events when single keys are pressed so one can check against it and prevent some special characters from entering the input field. all the other cases could send also some key value so whole word input could be prevented. but yeah I understand your point a bit better and I was quite frustrated trying to get a number only input going. now I changed input type to "tel" and can fake it sort-of.
I think, that we miss some point here. The point is - Google is in the fact the biggest company creating Android AND Chrome AND very popular keyboard + people are expecting working solution for the existing problem.

If teams inside Google can't find agreement, the it's even possible to make some replacement solution like showing own keyboard in Chrome (instead of opening standard one).

It's really not Space Shuttle and I'm really surprised that instead of seeing what we CAN do we still see what CAN'T do.

Come one! It's big company and I'm sure, that it has good qualified SWE.

Where is this Google spirit? Use it.
1) It would be philosophically wrong for Chrome to implement its own keyboard.  The role of a browser is not that of an OS.  (ChromeOS not withstanding. :-)  It would also be an incredibly jarring experience to switch from the system keyboard to a custom one, even assuming they were both the same layout and language.

2) The number of users that would benefit from this is tiny.  That good, qualified SWE would achieve more working on something that affects everyone.  Of course, Chrome is open-source so YOU could be that SWE and submit code to do what you want.  But I doubt such a change would be accepted because...

3) Web developers shouldn't be relying on keycodes in the first place, at least not for mobile devices, because they're incompatible with how a great many users want to use their device.  I understand that keycodes are convenient for some things, but the world has moved on from physical keyboards.

4) There already exist replacement keyboards that generate keycodes.  If your users are so specific and so dedicated that they're willing to use an alternate keyboard, it doesn't have to come from within Chrome.  Have them install the Hacker's Keyboard and use that.

I honestly don't mean to be harsh here -- I know text messages often come across that way -- but web developers need to find other ways if they want to operate in a the world of swiped-words, auto-fill, auto-correct, multi-language, voice-dictation, etc.  The absence of keycodes is a REFLECTION of how people use their devices these days, not a purposefully imposed limitation.
 Issue 864911  has been merged into this issue.
Hey, everyone

I've faced this issue not so while ago, and I have some thoughts.
I do agree separate keyboard is not an option. But the rest seems like "we don't care". 
Multiple ways for user to input info doesn't have anything to do with the problem. You can paste data into input using mouse on desktop since universe appeared - and its ok. Just because it doesn't generate keydown event, as there were no keydown. So I assume for any other kind of input there should be some reflection in generated event. But, seriously, if I assume user will press key, and I see he has done that, it is reasonable to give me info what was that key, otherwise its useless event. According to you can skip key property, as there were no physical key (how physical is virtual keyboard?), but you can't ignore code property, which is useless only in latest Chrome.
There is 2 main problems all explanations have to answer:
1. Ticket is opened in 2012 (!) but it appears only for my new phone, not for that I bought 2 years ago. So it seems you have no power/will to change anything.
2. Issue can be reproduced with input type text. With type tel everything works like expected. One may say those are different keyboards - that's true. But the browser is same.

If this issue is not in competence of Chromium dev team, its ok. This case there should be big arrow pointing to a ticket for Android team, instead there is a lot words about... philosophy. Maybe, there is Chrome Philosophy fork?
 Issue 868894  has been merged into this issue.
Regardless of if a software keyboard is sending a keyCode or not, something is resolving down to a character that it is sending to the browser so the browser knows what to put in the form field, right? If that's the case, why can't the browser provide us *something* to work with? A unicode code, an ascii code, the character passed in from the keyboard...? Create a new property if you have to. Please just give us something to work with. Why is this not possible?

The value is provided in the "beforeinput"/"input" events. These events respond to all IME input methods like voice, writing, etc. That is why we encourage you to use those instead of key events.
No, it is not working. On my previous phone it was working only with timeout. Without timeout value of input on input event is exactly same as it was before.
And there is still no answer on why issue exists only in Chrome, only for certain types of input. 
Why is there still support key events? There is no any good use of it after such "improvement"
It isn't Chrome.  It's the keyboard, specifically Gboard.  It simply does not provide keyup/keydown events to any app.  The reasons for this have been enumerated in detail so I won't repeat them here.
I just tested the "input" and "beforeinput" events. Both contained a property called "data" that contains the entire string in the input box after the key is pressed. I saw no other property that showed the key/character that was passed to the browser from the keyboard. Did I miss it? If not, can't that key be captured and provided in some property of the event object? It doesn't matter if it's a unicode code, ascii code, or the actual character. If there is something to go on it would be so helpful.
check out

data doesn't provide the entire string but of the text that is (or was) being committed. With IMEs you might insert/remove/change a range of the string all at once (for example spell checking replacing a word)
I just tested that link on my test phone using Chrome. Please see the attached file. You can see that the "input" is returning the entire string.
67.3 KB View Download
That image is from a Windows 10 machine and a PaleMoon browser (based on Gecko). See they don't fill in the data field on Gecko (they don't have that support yet).
I apologize, the last screenshot was from my desktop browser. However, you can see it's doing the same thing with the "input" that mobile Chrome is doing. I have attached the mobile Chrome screenshot.
158 KB View Download
Yes but commit the text by say placing a space. You are seeing the committed text adjust. It really depends on what your keyboard (that you have installed on the Android device) is telling the browser to do.
Here it is with a space and more letters. The phone is a Samsung SM-G900V using the default Samsung keyboard.
209 KB View Download
Re #303: That shows the behaviour that dtapuska@ is describing - the 'data' field on the event shows the newly-commit text.

The event viewer's "input field" column literally shows the entire contents of the input field, just to make it easier to correlate events with the state of the field when debugging - I suspect that's where the confusion is arising. :)
So as a workaround, I guess you could store the previous value of the input box somewhere and then compare it to the "data" value in the "input" event. That might be a usable workaround?
If you listen for the "beforeinput" event and call getTargetRanges() on the event you will be told about the indices that are going to change.
Showing comments 207 - 306 of 306 Older

Sign in to add a comment