Re: Issue 118639 in chromium: keydown and keyup events do not have proper keyCode (it's always 0)

[chro...@googlecode.com]

Comment #1 on issue 118639 by jac...@google.com: keydown and keyup events
do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

FWIW, on Nexus S Android Chrome, the keyCode returned is always 229.

Chrome version: 18.0.1025.166
Application version: Chrome 18.0.1025123
Webkit version: 535.19(trunk@113033)
JavaScript version: v8 3.8.9.24

[chro...@googlecode.com]

Comment #2 on issue 118639 by chip...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

I too have hit this, and it's blocking our support of VMware WSX on Android
for our release, unfortunately.

It seems there's never a keypress event. keypress is great when you want to
see what actually was pressed, as this will generally contain the
normalized key (shift-A vs. A) and unicode character ('A' vs 'a'). That
event never appears, from what I can tell, so we're left with keydown/keyup.

keydown in general (and even more so on Android) doesn't contain enough
information to identify the key. In most cases, you'll get the 'A' key, but
not 'a' vs. 'A', since it maps more closely to a physical key. (We don't
have physical keys on a touch screen, so it's a bit different in this case.)

On Android, as was noted, alphabetical keys, and most others, seem to
return keyCode 229. There's no normalized key value anywhere, nor a Unicode
character to base anything off of. Numeric keys, interestingly, seem to
produce unique key codes, but shifted ones did not.

This basically means that Google Chrome on Android is absolutely broken
when it comes to webapps needing any sort of custom key support. Input
fields are fine, and you can play games like see what the last character
is, but anything else is pretty broken.

My vote, if I had one, would be to restore keypress and use that to send a
normalized keycode and Unicode character, and then fix keydown to return
something proper. That way, developers don't have to start writing support
for a custom keydown, and Android will just do the right thing.

[chro...@googlecode.com]

Comment #3 on issue 118639 by chip...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Sorry, let me clarify. When I said "On Android, it's keyCode 229," I'm
talking about on Jelly Bean with the Nexus 7.

[chro...@googlecode.com]

Comment #6 on issue 118639 by sirparang: keydown and keyup events do not

have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

This issue is urgent for me.

please fix it.

[chro...@googlecode.com]

Comment #7 on issue 118639 by qin...@chromium.org: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

For developers, I think it is better to avoid expecting keycode on android.
The problem is that there are a lot of text suggestion related changes. For
example, you type "go", "good" and "gossip"will show up in the text
suggestion. The user might click "good" and "gossip" to change the current
text input, and it will also clear the composition under "go". If
developers are expecting keycode, it is hard to deal with the case above as
there is no keycode for user selections.
229 is the composition keycode for chrome, it is sent when user either hit
a key or hit a selection.

[chro...@googlecode.com]

Comment #8 on issue 118639 by patry.ni...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Should we inspect the text on each stroke (either 'change' or 'keydown'
events) ? This seems ok for small inputs but much harder to textarea.

Any advice for us developers on how to handle such cases ?

[chro...@googlecode.com]

Comment #9 on issue 118639 by freeman....@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

It's not always about detecting keycodes for characters, but even like
hitting a return key or backspace. It sure would be nice to not have to
work around this--in my case Android Chrome was the only browser that
failed to work. We had to add a button to submit just for Android Chrome.

[chro...@googlecode.com]

Comment #10 on issue 118639 by maglov...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

The same here. This key detection works for all browsers, except android
chrome. I made a simple currency edit field, in which the user needs only
to type numbers or backspace. I made a huge workaround to make it work on
Android Chrome, and as a side effect, at each type, the field bliks, since
I need to analyze all the text property, and properly replace the text
property to something adequate.

[chro...@googlecode.com]

Comment #12 on issue 118639 by qin...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

For android browser app, it sends the key code if I type a key, but it
sends nothing if I do a text selection. Also, it has no text composition
mode.

To better evaluate the case for chrome on Android, I think we need to
understand the use cases here. I am curious what your javascript is
expected to do if I select "chip" after I type "hip" on the keyboard.

[chro...@googlecode.com]

Comment #13 on issue 118639 by freeman....@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

In my use case, the only reason I used the keycode was to detect when the
return/enter key had been pressed, to submit a query. It was triggered from
a CodeMirror element (not a textarea/text input), so really I don't care
what someone selects for text selection--I just want to know when to
submit. It worked fine in every other browser and we added a separate
submit button just for Android, as a workaround. It seems silly that this
isn't supported. The reasoning that "it might do unexpected stuff if they
do a text selection" doesn't mean it shouldn't work normally for all other
use cases (and I think the others here feel the same way).

[chro...@googlecode.com]

Comment #14 on issue 118639 by sirparang: keydown and keyup events do not

have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

first, i'm not familiar with English

why i need keycode event?
i'm try to contenteditable for html5 attribute-based editor
when i typed key code that space
i have to sending for my server that current selection text
but, i can not catch 'space' keycode
I'm trying to make a simultaneous editing
I am sending it to the server based on the space, enter key event.

[chro...@googlecode.com]

Comment #15 on issue 118639 by daniel.m...@liftoffsoftware.com: keydown and

keyup events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

In my use case (Gate One: https://github.com/liftoff/GateOne/) I need to
capture individual keys as they're typed by the user in order to properly
emulate a terminal. For example, say you were running the 'top'
application and wanted to sort processes by memory. You'd need to type a
capital 'M'. In Chrome for Android that won't work since the keycode will
always be 0.

The use case should be irrelevant; the behavior of Chrome in this instance
is indisputably broken. I would argue that this is a severe bug since it
prevents whole categories of rich applications from working.

[chro...@googlecode.com]

Comment #16 on issue 118639 by chip...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

At VMware, we have a product (WSX) that allows a user to log in to their
VMs from any modern web browser and interact with the OS. Because of this,
we need to know exactly what keys are pressed in order to map them to
appropriate key codes sent to the VM.

What we do for every other browser is we create an <input type="text"/>,
shut off any auto-complete, focus the field, and listen for key events.
(This ensures a keyboard will pop up on mobile devices, as there's no API
for directly working with mobile keyboards, sadly).

For each key event we get, we intercept, block the default action, and then
do our work to transform and serialize the key code and send to the other
side.

The biggest feature request we have is "Please make this work on Android,"
to which we have to reply, "We can't. Chrome on Android is broken wrt key
events."

I can see the issue where auto-completion may cause some confusion with key
events. However, it's not much different, I don't think, from Safari on
iOS, which we have no problem with. There are two scenarios that come to
mind:

1) Auto-complete is on, and someone auto-completes (or uses voice input, or
something).

In this case, we get a "input" event that has the contents of the paste,
speech-to-text, auto-completion, whatever. We can check for this and do
something intelligent. (Hey, we suddenly have more than one character! The
user probably didn't type that themselves!)

Auto-completed entries and such don't generate keydown/keyup/keypress
events. The individual keys do. So, I type "he" and auto-complete
the "hello". I'll see the first two key events, then see the input event,
and I can be smart about my handling of it all.

2) Auto-complete is turned off for the field.

This is the mode we're in for WSX.

We know we won't auto-complete on iOS, MacOS, whatever. Android, though,
ignores our request to turn off auto-complete, so that's a problem for us.
Assuming, though, that that was changed to behave like every other browser
and platform out there we've tested with, we wouldn't have the concern
about what you do with auto-completed entries. We'd just deal with key
presses, like we get to for every other browser.


This is pretty clearly broken and a major show-stopper for any web-based
product that needs to do anything more advanced than "my text field has
changed" or "submit this form," which, given this bug report and some
research on Stack Overflow and blogs, is certainly affecting webapp
developers out there.

Android's in a great position to be able to become a great platform for the
newer, more advanced interactive mobile webapp market. But not with this
key input behavior.

[chro...@googlecode.com]

Comment #17 on issue 118639 by daniel.m...@liftoffsoftware.com: keydown and

keyup events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

I am in complete agreement with the VMWare person on this one... This is a
show-stopper bug. I opened it 7 months ago and I am quite surprised that
there has been no progress on it thus far.

BTW: VMWare should add Gate One as an HTML5 serial console (terminal)
option alongside WSX :) . Fill out the contact form at liftoffsoftware.com
and I'll help you get it working =D

[chro...@googlecode.com]

Updates:
Owner: auri...@chromium.org

Comment #18 on issue 118639 by qin...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #19 on issue 118639 by jdou...@basis.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

To echo Comment #16 from VMware, this is a serious bug; it breaks any sort
of formatted text input that depends on trapping key events. The solution
is pretty straightforward; autocomplete="off" should disable the correction
suggestions that normally appear at the top of the keyboard. And when
correction suggestions are off (including when turned off globally in
Android keyboard settings, Show correction suggestions, the standard
JavaScript key events -- including keypress! -- should be reported. I
tripped over exactly this situation with the BlackBerry PlayBook:

http://supportforums.blackberry.com/t5/Web-and-WebWorks-Development/Can-Predictive-Input-be-selectively-disabled-for-a-single-lt/m-p/1665929/highlight/false

[chro...@googlecode.com]

Comment #22 on issue 118639 by Carsten....@googlemail.com: keydown and

keyup events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

This issue is also blocking our project where we want to support editing of
large text directly in the browser.

[chro...@googlecode.com]

Comment #23 on issue 118639 by jones.ra...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

It is crazy that this browser doesn't at least have the option to set the
virtual keyboard behavior (particularly for keycodes set by
onkeydown/onkeyup events) to emulate a physical keyboard. Better yet, have
the default behavior to work just like does on desktop machines and have an
override option to let it behave in this new way.

As it is, the current "feature" clearly pushes us to recommend browsers
other that Chromium for our mobile users. Assuming that a site does not
need to filter keystrokes is really a short-sighted change in behavior.
This is really a step backwards in basic functionality.


--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #24 on issue 118639 by rj81in...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Now that Chrome Mobile browser gives event.keyDown return value as 229 for
any key press on inbuilt Android Samsung keyboard, most of above issues
will be resolved if you add just another condition check for this value.
Correct me if wrong.

[chro...@googlecode.com]

Comment #26 on issue 118639 by rj81in...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Now that Chrome Mobile browser gives event.keydown keyCode return value as

[chro...@googlecode.com]

Updates:
Cc: -oli...@chromium.org
Labels: -Feature-Touch Feature-TextInput

Comment #27 on issue 118639 by auri...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Sending keyCode for entering text using IME makes very little sense in most
cases. They only time it can be justified if the user is using Latin IME
with that keyboard committing each character one by one (calling
InputConnection.commitText()). That way each key could be translated to a
keyCode and be sent to JavaScript.

However, this breaks down in a lot of other cases. For example:
1. If the keyboard is entering text by multiple characters at the type (eg.
swype using commitText with text longer than one character).
2. If the keyboard is appending one character to composition every time
using setComposingText(). This breaks down because keyboard can decide to
autocorrect or replace entire work at any time - thus causing the keyCodes
that would be sent for each additional character to be wrong.
3. If the keyboard is phonetical.
4. If the keyboard is Japanese and modifies an entered character on each
new button click (eg. built in android Japanese IME).
... there are probably other cases here too.

Possible way to solve this bug:
a) Set the type of the input box to password, to force the android software
keyboard to show a password keyboard, usually it's just a bare US qwerty
keyboard without any auto-completion/auto-correction feature. This keyboard
will generate exactly key events wanted. This approach actually doesn't
need to change anything from our side.
b) Set flag TYPE_TEXT_FLAG_AUTO_COMPLETE to EditorInfo.inputType to ask the
android keyboard to disable auto-completion. Not all android keyboards obey
this flag, especially those non-latin keyboards.
c) Set flag IME_FLAG_FORCE_ASCII to EditorInfo.imeOptions. This flag was
only available since SDK version 16, so I doubt if there is any android
keyboard (except the built-in Android LatinIME) support it.

Comments? Ideas?

[chro...@googlecode.com]

Comment #28 on issue 118639 by dono...@squareup.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

While it may be true that there are circumstances in which the keyCode
value doesn't make sense, there are a large number of cases where it does.
As other commenters have pointed out the behavior of Chrome for Android in
this regard is non-standard and breaks many scripts that rely on capturing
key events. For a project I'm working on Chrome for Android is essentially
dead in the water and unsupported due to this bug. I'd love for that not to
be the case.

[chro...@googlecode.com]

Comment #29 on issue 118639 by mayt...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

This issue impedes the development of the mobile service at my company as
well.

To address #27 for all points: just send the keyCode of the pressed
softkey, whatever comes out. On the desktop, you can also do
paste/autocomplete etc. stuff, but there are still proper keyCodes if I do
Ctrl+V. Everyone got used to it and can get along with the inconsistencies
you described.
IMO, it's still better to have some information about key inputs than to
have nothing. As a suggestion - set the keyCode to 229 if you get more than
one key coming from the keyboard, otherwise - set a normal corresponding
keyCode.

[chro...@googlecode.com]

Comment #31 on issue 118639 by qin...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

I think we can use a similar approach android browser uses.

When committing multiple characters, simply send 229. But for the rest
cases (only one character change at the cursor), we should send the keycode.

[chro...@googlecode.com]

Comment #33 on issue 118639 by supp...@toremote.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Even you Set the type of the input box to password, you can not capture the
backspace key event, another strange thing:
e.preventDefault() will not work on keydown/up event, you can still get
text entered, but backspace key will stop working.

Why Android Chrome's behavior is different with all other browsers? We can
capture backspace keys on all other mobile browsers. Every time we have to
tell our customers you have to use iOS instead of Android. That give me an
impression: Android is like an abandon ship, Google only cares about Chrome
OS for now.

[chro...@googlecode.com]

Comment #34 on issue 118639 by auri...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Android software keyboards can choose whether to send key events or not.
Most of them are not sending any key events and instead use IME commands to
achieve the same affect. For example Android's stock LatinIme does not send
back space key anymore when it is deleting text, instead it is using
DeleteSuroundingText(1,0). Since there are no key events being sent, the
only way for Chrome to figure out what key would the previous call
represent would be guess work. For example, if we receive
setComposingText("a",1) and then receive setComposingText("ab",1), we have
exactly same about of information as JavaScript would by querying the value
of the input field. We would have to look at the diff, find if the diff is
one character, then convert that character to a keycode (that's assuming
user did not use some sort of swiping functionality to enter multiple
characters at once). The same can be done directly on JavaScript.

There is work being done on better IME API
(https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html) by
Googlers. Please contact them if you have any concerns about that this API
and if you need an extension to this API that would be used for wide
audience of developers.

[chro...@googlecode.com]

Comment #35 on issue 118639 by dono...@squareup.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Thanks for the background information, #34. From the perspective of a web
developer this sounds like Android's software keyboards are broken. I know
very little about IME and it very well may be a better API for handling
text input than what the existing web standards were built on, but the
bottom line is that Chrome for Android does not adhere to those existing
standards and therefore appears broken.

But please, by all means, work toward better standards. If there is
something fundamentally broken about the existing web keyboard events then
we should fix them. But we should do it together with enough backward
compatibility to allow for applications that work everywhere else to work
on Chrome for Android, too.

Do you have any insight into why the stock Browser application on Android
does not have this issue? Does it not use the same keyboard, or does it do
the kind of diffing you describe in your example?

[chro...@googlecode.com]

Comment #37 on issue 118639 by supp...@toremote.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Test results on Nexus 7, stock Android Keyboard:

Using a native app(Remote RDP), we can capture BACKSPACE key in View's
onkeydown/up event.

But in Chrome, we can not (even not on a password type input). On Firefox,
we can. As I remember, the previous Chrome (16 or 18?) can capture the
BACKSPACE key.

There must be some other reasons behind this.

[chro...@googlecode.com]

Comment #39 on issue 118639 by sup...@toremote.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

IME does send key events to InputConnection for non-printable keys, but if
you don't handle it in sendKeyEvent, onkeydown/up event will be triggered.
You should not translate DEL key to deleteSurroundingText here, this is
based on assumption that apps only need to deal with InputConnection, but
actually an app also need to deal with external (USB) keyboard, that's be
processed in onkeydown/up.

[chro...@googlecode.com]

Updates:
Cc: ko...@chromium.org

Comment #40 on issue 118639 by kenji...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

+kochi@ author of the IME API mentioned at comment #36.

AFAICT, you should be able to solve your use case in a robust way by using
the DOM level 3 composition events that aurimas@ highlighted:

compositionstart
compositionupdate
compositionend

node.addEventListener('compositionupdate', onCompositionUpdate, false);

[chro...@googlecode.com]

Comment #45 on issue 118639 by auri...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

#43: Not all the Android keyboards send backspace events to delete, in fact
starting in Android 4.1 LatinIME started sending
InputConnection.deleteSurroundingText(1,0) instead of keyEvent delete.

[chro...@googlecode.com]

Comment #46 on issue 118639 by sup...@toremote.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Chrome will not fire an backspace event even the IME sending backspace key
event instead of deleteSurroundingText. The good thing about keyevent is
it's compatible with existing web applications and good for developers,
like on IOS, LatinIME will always send keyevent even for printable
characters.

Actually most of IME end keyevent on Ctrl/Shift, backspace, del etc. on my
nexus 7, the IME is still sending keyevent for backspace.
All external bluetooth/usb keyboards (from what I tested) will send key
events.

Basically, I think sending deleteSurroundingText instead keyevent for
backspace (non-printable keys) is a wrong decision. It's good for final
users, but a disaster for developers, how can we know if a backspace key is
pressed. No any other browsers are doing same thing.

[chro...@googlecode.com]

Comment #48 on issue 118639 by sup...@toremote.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

I'm using an Android application (Remote RDP) . I just did another test and
here is the log I got:

D/REMOTE (25323): kkkkkkk Down:KeyEvent { action=ACTION_DOWN,
keyCode=KEYCODE_D
EL, scanCode=0, metaState=0, flags=0x6, repeatCount=0, eventTime=48581030,
downT
ime=48581030, deviceId=-1, source=0x0 }

Android version on this nexus 7 is 4.2.2.

[chro...@googlecode.com]

Updates:
Cc: yoic...@chromium.org

Comment #52 on issue 118639 by yoic...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #54 on issue 118639 by jordan.h...@analoganalytics.com: keydown and

keyup events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

#53, since this is a long thread, what specifically was fixed in Chrome
Beta?

[chro...@googlecode.com]

Comment #55 on issue 118639 by sup...@toremote.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

#54, for me, I think "keycode is zero" is acceptable if it's a printable
character, but it's not acceptable for non-printable characters, like
backspace, return.

My web page could capture the backspace someday and I thought this was
fixed, but looks like the fix only stayed for several days and you can not
capture backspace key again in Chrome beta right now.

[chro...@googlecode.com]

Comment #56 on issue 118639 by bwalker...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Any update on this? My website needs to detect keycodes for a custom search
box, and the website works on every browser except Android Chrome because
of all keycodes are zero except for backspace(which is 8). This is a
serious bug, and needs to be fixed. Any updates?

[chro...@googlecode.com]

Comment #57 on issue 118639 by p...@devshed.nl: keydown and keyup events do

not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Any status on this? This is basic browser / Javascript functionality which
should work on any platform.

[chro...@googlecode.com]

Comment #58 on issue 118639 by nazsh...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

in my case, http://podio.github.io/jquery-mentions-input/ in chat function
is not functioning because can't detect the keycode

[chro...@googlecode.com]

Comment #59 on issue 118639 by dwoldr...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Seeing as how latest comment in this bug is 4 hours old, I know I can stop
banging my head against the brick wall trying to figure out what I am doing
wrong.

It would be super if mobile chrome could disable
autosuggest/autocomplete/autocapitalize and would send keypress events
after each key entered. Please work like how iOS does? I will *not*
workaround something as fundamental as keypress trapping in a textarea. My
app will simply not respond on your browser and I will point users to this
bug to complain. My onkeypress code works fine in desktop Chrome.

THANKS!

[chro...@googlecode.com]

Comment #60 on issue 118639 by amy_gar...@mgic.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Also having app issues because android is not detecting keycodes for a
masked dollar field. iOS seems to work fine though. Agree with #56 that
this is a serious bug and needs to be fixed.

[chro...@googlecode.com]

Comment #61 on issue 118639 by benjamin...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

For what it's worth, I'm handling a backspace/delete key event on Android
Chrome in specifically this one fashion. I'm using jQuery. Note that "#inp"
is a hidden field somewhere with a non-breaking space character already
inside of it.

$('#inp').on('input', function(event) {
if ($(event.target).val() == '')
// do something that normally would have required the backspace key
});

Hope this helps someone until the Android / Chromium teams gets this mess
straightened out.

[chro...@googlecode.com]

Comment #62 on issue 118639 by edleb...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

How can something as fundamental as keypress/keydown/keyup events be broken
in android chrome? Stripe now has a nice library for formatting credit
card numbers / expirations/ cvc codes that is useless (even harmful) on
android chrome.

[chro...@googlecode.com]

Comment #63 on issue 118639 by kenji...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Issue 270647 has been merged into this issue.

[chro...@googlecode.com]

Comment #64 on issue 118639 by thiago.unicamp: keydown and keyup events do

not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Event KeyPress works in Chrome for iOS but doesn't work in Chrome for
Android.

[chro...@googlecode.com]

Comment #66 on issue 118639 by jakalten...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Please fix it, I can't understand why this would be the only browser who
doesn't support keyevents...

[chro...@googlecode.com]

Comment #67 on issue 118639 by aw...@pizzeria.de: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

This issue has remained unchanged since over one year, I guess I have to
recommend my users to choose another Browser on Android, like Dolphin. That
one is using the same software keybord as Chrome while not only sending
correct keycodes in keydown and keyup but also providing the input
character with keypress event!
All what is said about the reasons why Chrome behaves like it is doing
because of auto completion, text suggestion, ... seems to me like a
statement "we know that we better should correct this but we don't like
to". Other browsers in the same environment are able to provide keyboard
input in a standard way!

[chro...@googlecode.com]

Comment #69 on issue 118639 by leadbett...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Guys I can't believe this is the case on Android. You're killing me here!

Test page, all return 0
http://www.cambiaresearch.com/articles/15/javascript-char-codes-key-codes

[chro...@googlecode.com]

Comment #70 on issue 118639 by heinzme...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Now I am confused - I checked the site mentioned below with the latest
version of Chrome for iOS - and it worked properly?!

[chro...@googlecode.com]

Comment #74 on issue 118639 by goloj...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

My temporary solution is watching last char from inputfielt
$(inputField).bind('keyup', function(event) {
var userInput = $(this).val();
if (event.which === 0){
event.which = userInput.charAt(userInput.length-1).charCodeAt(0);
}
...

[chro...@googlecode.com]

Comment #75 on issue 118639 by bazzi...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Maybe there will be a temporary solution for any need, but every workaround
has contraindications.
What happen if user move the cursor on inputfield? What if user uses a
phisical keyboard with a Android device? Will you be able to capture CTRL
and other non-printable keys?
This is a bug and it seems it will not be solved in short times. This
behaviour on Android seems wanted by Chrome team.
Because of this I don't even know if they want to solve this bug...

[chro...@googlecode.com]

Comment #76 on issue 118639 by dono...@squareup.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

goloj (#74), that works fine if the user is always entering text at the
end, but they may have positioned the cursor somewhere in the middle.
You'll have to be more clever to do that properly.

[chro...@googlecode.com]

Comment #77 on issue 118639 by vazgen.m...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Strange, why this took so long time!

[chro...@googlecode.com]

Comment #78 on issue 118639 by cdr...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

I believe a keydown event should always be sent with a keyCode because:

* any arguments about autocorrect/autocomplete are irrelevant for keydown
* iPad/iPhone sends keydown events and sets keyCode
* JavaScript code for any browser should never expect a keypress for every
keydown
* JavaScript code already deals with keyCodes on keydown not generating
keypress (e.g. select some text and press backspace or a key etc).
* arguments it can't be done (re. aurimus #27 #34) just don't apply to the
keydown event (I do understand why the problem can be argued for the
keypress event).

My particular problem is that there is no keydown event generated if
backspace is pressed when the input is empty - as per
https://code.google.com/p/chromium/issues/detail?id=184812 - which I am
sure is a side effect of this issue. I checked the keydown, keypress,
keyup, compositionstart, compositionupdate, compositionend events and no
event is generated.

bazilla (#75) a physical keyboard (USB or bluetooth) sends through the
events correctly with correct keyCode. Other virtual keyboards such
as "Hackers keyboard" may send through the keyboard events correctly.

[chro...@googlecode.com]

Comment #79 on issue 118639 by bazzi...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

cdr...@gmail.com (#78) I've tried "Hackers keyboard": keyboard events
always send keyCode=0 and charCode=0 on keydown and keyup.
No keypress events are fired.

[chro...@googlecode.com]

Comment #80 on issue 118639 by a...@hazteoir.net: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Yes, this is really annoying. The funny thing is that numeric keys (0-9)
send the normal keypress events, but the rest only send the keydown/keyup.
This is my littele piece of code:


$(this).keypress(function(){
if (!$(this).data('changed')) {
$(this).css('color',typing_color);
$(this).val('');
$(this).data('changed', true);
}
});

This is for in-field labels, that disappear when the user enters the first
character. Because of this bug, this functionality is not working. I've
tried to replace keypress with keydown, and in that case the function is
triggered, but then the first character is 'swallowed' by Chrome (if it's
not a number!).

[chro...@googlecode.com]

Comment #81 on issue 118639 by cdr...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

I tested mobile/touch devices and the following *WORK* (send keydown event
with correct keyCode - only tested keydown):

KEYBOARD; BROWSER; OS; DEVICE;
Touch keyboard; Mobile Safari/7534.4.3 (534.46); iOS 5.1.1; iPad 2:
Touch keyboard; Mobile Safari/8526.25 (536.26); iOS 6.1.3; iPad 4:
Touch keyboard; Mobile Safari/9537.53 (537.51.1); iOS 7.0.4; iPhone 4:
Touch Keyboard; Internet Explorer 10.0; Windows Phone 8; Nokia 520:
USB Keyboard (OTG cable); Chrome 31.0.1650.59; Android 4.4; Nexus 10:
USB Keyboard (OTG cable); Chrome 31.0.1650.59; Android 4.3; Galaxy Nexus:
USB Keyboard (OTG cable); Native Android Browser 4.3-776638 (534.30);
Android 4.3; Galaxy Nexus:
Touch Keyboard and Handwriting Panel; IE11.0 (tested both Desktop and
Modern); Windows 8.1 Pro; Dell S2240T touch screen:
Google Keyboard 2.0.19123.914326a; Native Android Browser 4.3-776638
(534.30); Android 4.3; Galaxy Nexus:
Hackers Keyboard v1.33; Native Android Browser 4.3-776638 (534.30);
Android 4.3; Galaxy Nexus:
Swype 1.6.3.22544; Native Android Browser 4.3-776638 (534.30); Android 4.3;
Galaxy Nexus:
Google Keyboard 2.0.19123.914326a; Native Android Browser 534.30; Android
4.0.3; Huawei U8666N:
Samsung Keyboard; Native Android Browser 534.30; Android 4.1.2; Galaxy S
mini III;
Google Keyboard 2.0.19123.914326a; Native Android Browser 534.30; Android
4.1.2; Galaxy S mini III;


Virtual keyboards FAIL for:
Chrome 31.0.1650.59 on Android (fires keydown event but keyCode is 0)
Firefox 25.0 (fails to fire keydown event)
I tested Hackers keyboard, Swype, Google Keyboard, Samsung Keyboard and
they all failed.


Google Keyboard on Android Chrome oddities:
(A) a physical keyboard fires keydown events with correct keyCode on
Chrome on Android (and Firefox on Android) - tested using USB (OTG)
keyboard plugged into Nexus 10 or Galaxy Nexus.
(B) GO key always fires keydown event and keyCode=13
(C)Number keys only (without Alpha keys) fires keydown events with correct
keyCodes e.g. Empty field, Key 1 followed by Key 2 sends keydown with
keyCode=49 followed by keydown with keyCode=50
(D) BACKSPACE never fires a keydown event for a type=number input
(E) [A-Z] followed by a number fires keydown with keyCode 0 for both keys

So:
(i) All keyboards fire correct keydown event on Android Native Browser.
(ii) No virtual keyboards fire correct keydown events on Android Chrome.

We use the keydown event in input boxes for validation (prevent some
keypresses to help new users avoid typing errors), and we use the keydown
event for keyboard shortcuts (for power users who use our web app every day
from tablets).

[chro...@googlecode.com]

Updates:
Labels: Hotlist-DevRel

Comment #82 on issue 118639 by mattga...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #85 on issue 118639 by jeffwhel...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

This is crazy! How can this bug be open for so long? I just spent most of
the past year building a pretty large AngularJS app that is practically
non-functional on Android because of this issue. As others have expressed,
Keypress events are a fundamental part of the web platform. I am shocked
that with all the great work Google does with the web platform standards,
they can't fix this in over a year and a half.

[chro...@googlecode.com]

Comment #86 on issue 118639 by thiago.unicamp: keydown and keyup events do

not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Please, anybody here fix this bug.

[chro...@googlecode.com]

Comment #87 on issue 118639 by sup...@toremote.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

This issue and issue 33062 basically killed the keyboard input of Android
Chrome.

[chro...@googlecode.com]

Updates:
Labels: -Type-Feature OWP-Standards-Compatibility Type-Compat

Comment #88 on issue 118639 by paulir...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

@aurimas, Can you give an update on this ticket? It's in our top 10 most
starred Chrome on Android bugs.

As comment 81 points out, this is a BIG compatibility issue. Classic
Android Browser and iOS provide no problems here and we're breaking
expectations.

[chro...@googlecode.com]

Comment #89 on issue 118639 by sup...@toremote.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Sorry, it should be issue 330662 in my previous post #87

[chro...@googlecode.com]

Updates:
Status: Untriaged
Owner: kenji...@chromium.org
Cc: auri...@chromium.org

Comment #93 on issue 118639 by kenji...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Status: Started

Comment #95 on issue 118639 by kenji...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Discussion started, will provide a summary of the plan asap.

[chro...@googlecode.com]

Comment #96 on issue 118639 by kenji...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

We are discussing how other mobile browsers are handling this in order to
find a (hopefully) quick solution while we think about a better solution
Which might involve new APIs.

#92: Chris, can you tell me how things are working with other Android
mobile browsers and Firefox in particular?
- does the issue with the backspace key also exists there?
- if it does but you have a workaround, would you mind explaining it?

Our current preference goes for FF's model, so I am interested to hear if
this would work for you or not.

FF's model as we understand it: sends key events for one character
commitText() and does not send key events when composition is taking place
(underline in chrome). We believe that no event would be sent for some keys
such as backspace/delete.


Note: webapps developers will have to pay special attention when dealing
with say a Japanese input method (involves composition events:
http://www.w3.org/TR/DOM-Level-3-Events/#events-compositionevents).

[chro...@googlecode.com]

Comment #97 on issue 118639 by sup...@toremote.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

In my previous test. Firefox did send backspace/delete keycode. For IME,
like Japanese or Chinese. You can use textInput event which is more
convenient than commitText, but right now textInput event is broken in
Android Chrome too because of issue 330662.

In the old version of Android Chrome, you can get backspace/delete keycode
if you are using textarea instead of input, but don't know since when, you
can not get backsapce/delete keycode if there is no characters in the
textarea.

[chro...@googlecode.com]

Comment #100 on issue 118639 by kenji...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

#91: from our direct conversation, I believe your issue is different. I
have filed issue 335421 for your use case. Feel free to star this one to
get updates.

[chro...@googlecode.com]

Comment #101 on issue 118639 by mfrn...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

#100: I do not think that my issue is different then this issue... So, I
believe that if this issue will be solved and closed then my problem will
be solved too... the problem is in incorrect behaviour of keypress, keydown
and keyup events.

[chro...@googlecode.com]

Comment #102 on issue 118639 by MSAOffic...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

#96: Hi Kenji - we aren't able to get backspace keycodes in Firefox either,
so I'm not sure that their model would resolve our issues. We tried a few
workarounds, but nothing ultimately worked for us. Thanks for your help on
this!

[chro...@googlecode.com]

Comment #103 on issue 118639 by patry.ni...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

#102 I think you can get backspace keycodes in Firefox when firing
keypress/keydown event on an empty <input>. It does not send the correct
keycodes if you started writing.

You can test it here: http://api.jquery.com/keypress ,
http://api.jquery.com/keydown .

You can find a library which worked around this issue by having a hidden
textarea which is always empty to capture backspace: http://mathquill.com/.
I hope this can help other.

[chro...@googlecode.com]

Comment #105 on issue 118639 by vazgen.m...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

let's wait and celebrate 2 years! I have already put message "please use
another browser".

[chro...@googlecode.com]

Comment #106 on issue 118639 by andrew.w...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

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

Any news on this bug?

[chro...@googlecode.com]

Comment #108 on issue 118639 by jfla...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Please fix, this is absolutely critical for mobile web apps.

[chro...@googlecode.com]

Comment #110 on issue 118639 by emil.g...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

This is crazy?! Fix it.

[chro...@googlecode.com]

Updates:
Status: Available
Owner: ---
Cc: kenji...@chromium.org

Comment #111 on issue 118639 by kenji...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

The relevant teams have been reached out.

[chro...@googlecode.com]

Comment #115 on issue 118639 by x4TR...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

I am only having this issue on my mobile device, but not on my desktop
(both browsers are the latest versions). Aren't both Chrome browsers using
the Chromium engine? I wonder what the discrepancy is? Anyone have a
workaround going in the meanwhile?

[chro...@googlecode.com]

Comment #116 on issue 118639 by x4TR...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Actually ignore the first part of my comment; I can see that this issue is
specifically for the Android version and not the desktop.

[chro...@googlecode.com]

Comment #117 on issue 118639 by plbow...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

It looks like there is some positive movement forward on this issue. Thank
you, Kenji, for taking the initiative.

Meanwhile, is there any way to detect the loss of functionality? It
appears that the keydown and keyup and keypress functions still exist in
the object model, but they just don't return anything useful. If they
don't do anything useful then could they be removed from the model? That
way I could detect if it exists and use the oninput event instead (kludge
though that is). As it is I am reduced to trying to figure out which
browser/OS combinations work and which don't work and then responding to
the user agent string which is really not the way we should be going...

RE the big picture issue... Can't we treat a text replacement (I
type "teh" and then select "the" as the correction) just like a
select/paste? So I would get a keydown for t, for e, and for h, but then
the correction would act like an implicit select & paste had occurred
(which don't really involve keypresses and thus wouldn't generate keyboard
events). I'm not familiar with the internals, but this seems like the only
logical way to move forward since the keyboard is not really involved in
the correction...

But, as I mentioned above, the bigger issue for me is getting a way I can
reliably detect the situation so I can implement my workaround.

[chro...@googlecode.com]

Comment #118 on issue 118639 by MYak...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

I need this fix!

[chro...@googlecode.com]

Comment #119 on issue 118639 by m.lewand...@cksource.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

It's a major bug, I'm surprised it hasn't been fixed yet. Is there any
progress on that issue?

[chro...@googlecode.com]

Comment #121 on issue 118639 by thiago.unicamp: keydown and keyup events do

not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

\o/

[chro...@googlecode.com]

Comment #122 on issue 118639 by zhgjiang...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

please fix, key event is very important for developers.

[chro...@googlecode.com]

Comment #123 on issue 118639 by ashwin.d...@visebasoft.com: keydown and

keyup events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Please please.... my web app is broken and I dont want some hack solution

[chro...@googlecode.com]

Comment #125 on issue 118639 by ko...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

FYI

This is the latest DOM level3 spec about keycode
https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#legacy-key-attributes
> Implementations that are unable to identify a key use the key value '0'.

[chro...@googlecode.com]

Comment #126 on issue 118639 by chip...@gmail.com: keydown and keyup events

do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

That would make sense if it weren't possible to map to any key code, but
every other browser on Android, including the original Android browser, has
shown that that's not the case. Given that, I don't think this portion of
the spec applies.

[chro...@googlecode.com]

Comment #127 on issue 118639 by ko...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Even if Chrome can emulate some of keyCode from virtual keyboard input,
it can't be perfect anyway.

Other than cases that legacy web apps that depend on keyCode,
what are your legitimate use cases that definitely need exact keyCode,
which can't be implemented using composition events etc. which are
available to today's Android Chrome?

[chro...@googlecode.com]

Comment #129 on issue 118639 by ko...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

We cannot provide any specific date or plan of the future.

We are gauging the importance and priority for fixing this.

[chro...@googlecode.com]

Comment #130 on issue 118639 by ko...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

As Apple announced that iOS6 would adopt third-party IMEs and new keyboard
model,
I guess sooner or later iOS devices will have the same issue.

So for future-proof, web apps should work as is with the current chrome on
Android
without depending on keyCode.

We recognize there are legacy desktop web apps which are not compatible
on Android devices, which are serious for those who depend on such apps,
but if apps could be fixed e.g. with composition events, they should be
fixed.

[chro...@googlecode.com]

Comment #133 on issue 118639 by bcwh...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

I believe the point is simply that there is no perfect solution. Mobile
devices inherently have vastly different input mechanisms than the
traditional keyboard that many Web apps are handling. I can't speak about
iOS, but Android's IME does not emulate a keyboard. There are some
installable keyboards that do, but most will not.

I'm certainly going to be doing my best to improve upon what exists and
provide a workable solution for many cases, but there is always going to be
some places where the adapter fails to match a true keyboard.

[chro...@googlecode.com]

Comment #134 on issue 118639 by Carsten....@googlemail.com: keydown and

keyup events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

This sounds promising and I am looking forward to see any progress. I see
your points but the current behaviour looks strange to me. Even if there
are no IME composition events the keydown/keyup events provide no correct
keyCode. This can be seen if you just enter numbers or special characters.
For our project it would be sufficient to get IME events and in cases where
no IME events are notified the keydown/up events have proper keyCodes.

[chro...@googlecode.com]

Comment #135 on issue 118639 by auri...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

#134: can you please specify exactly what are the cases where you do not
get a composition event and only a keydown/up with incorrect keyCodes?

Please add device model, android version, chrome version, IME name +
version, special characters and keys that cause this behavior.

[chro...@googlecode.com]

Comment #138 on issue 118639 by Carsten....@googlemail.com: keydown and

keyup events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

Just checked with my Nexus 4, Android 4.4.2 using Chrome 35.0.1916.141 and
now I can see keyCodes for numeric keys, but not for other keys (like +-)
and no composition events. You can check it yourself with the following web
page.

http://www.danilatos.com/event-test/ExperimentTest.html

[chro...@googlecode.com]

Comment #139 on issue 118639 by gregored...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

I've found another issue which may be related?

I need to detect the delete key being pressed, especially when the input
field is empty.
After a keyup I check the input value and if the length has reduced then
the delete key has obviously been pressed.

To catch a delete being pressed when the input field is empty I've added an
invisible character (\uFFFC) to the start. If value.length === 0 then I add
the invisible char to the input field again. ie. (the input always has 1 or
more characters in it).

if (input.value.length === 0) {
console.log('delete pressed!')
input.value = '\uFFFC';
}

This works perfectly in Chrome on my laptop but fails on my Android device
(Nexus 5, Android 4.4.3, Chrome 34.0.1847.114). Adding content to the input
field doesn't get picked up by the VKB... pressing delete does nothing,
neither keyup, keydown fire. It seems that the VKB is tracking what has
been typed/deleted, so any characters that are added/deleted without using
the VKB are ignored.

In short, if I add/change/replace text in an input with javascript the
keyboard (delete key) should still work!!

Anyone know of a fix / workaround??
(Or another solution to detect the delete key being pressed)

[chro...@googlecode.com]

Comment #140 on issue 118639 by AndrewSt...@gmail.com: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

you guys are insane... you have no idea how serious this bug is. I'm
terribly disappointed!

[chro...@googlecode.com]

Comment #141 on issue 118639 by guo...@chromium.org: keydown and keyup

events do not have proper keyCode (it's always 0)
http://code.google.com/p/chromium/issues/detail?id=118639

@gregoredwards, the issue that no key event is generated when pressing DEL
key is tracked in a separate bug 184812 and a fix was landed yesterday.

I am investigating if it is possible to send DEL keycode when DEL key is
pressed in non-composition mode.

[chro...@googlecode.com]

Comment #142 on issue 118639 by bugdro...@chromium.org: keydown and keyup

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

http://code.google.com/p/chromium/issues/detail?id=118639#c142

------------------------------------------------------------------
r283989 | guo...@chromium.org | 2014-07-18T03:09:52.583636Z

Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/content/public/android/javatests/src/org/chromium/content/browser/input/AdapterInputConnectionTest.java?r1=283989&r2=283988&pathrev=283989
M
http://src.chromium.org/viewvc/chrome/trunk/src/content/public/android/java/src/org/chromium/content/browser/input/ImeAdapter.java?r1=283989&r2=283988&pathrev=283989
M
http://src.chromium.org/viewvc/chrome/trunk/src/content/public/android/java/src/org/chromium/content/browser/input/AdapterInputConnection.java?r1=283989&r2=283988&pathrev=283989
M
http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/render_widget.cc?r1=283989&r2=283988&pathrev=283989

Send the real key code in deleteSurroundingText

On android, when user presses DEL or FORWARD_DEL using IME, Chrome
generates key events with 0 keycode. This breaks lots of websites who count
on having the real keycode in the key event listeners, especially for the
control keys such as DEL and FORWARD_DEL.

This CL fixes the issue for the most common case when a single char is
deleted. Instead of triggering deleteSurroudingText path with synthetic key
events of key code 0, Chrome sends native key events with real key code.

BUG=118639

Review URL: https://codereview.chromium.org/393933004
-----------------------------------------------------------------

[chro...@googlecode.com]

Comment #143 on issue 118639 by bugdro...@chromium.org: keydown and keyup

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

http://code.google.com/p/chromium/issues/detail?id=118639#c143

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/25402eb26f2f05b5105523057f06532eaac58764

commit 25402eb26f2f05b5105523057f06532eaac58764
Author: guo...@chromium.org
<guo...@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Fri Jul 18 03:09:52 2014

Send the real key code in deleteSurroundingText

On android, when user presses DEL or FORWARD_DEL using IME, Chrome
generates key events with 0 keycode. This breaks lots of websites who count
on having the real keycode in the key event listeners, especially for the
control keys such as DEL and FORWARD_DEL.

This CL fixes the issue for the most common case when a single char is
deleted. Instead of triggering deleteSurroudingText path with synthetic key
events of key code 0, Chrome sends native key events with real key code.

BUG=118639

Review URL: https://codereview.chromium.org/393933004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@283989
0039d316-1c4b-4281-b951-d872f2087c98

[chro...@googlecode.com]

Comment #144 on issue 118639 by bugdro...@chromium.org: keydown and keyup

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

http://code.google.com/p/chromium/issues/detail?id=118639#c144

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/87389c9d9a3c762355b08b191a28d39585a979a0

commit 87389c9d9a3c762355b08b191a28d39585a979a0
Author: bcw...@chromium.org
<bcw...@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Thu Jul 24 02:12:51 2014

Send correct key-codes when doing composition events instead of always 0.

BUG=118639

Review URL: https://codereview.chromium.org/373523002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@285108

[chro...@googlecode.com]

Comment #145 on issue 118639 by bugdro...@chromium.org: keydown and keyup

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

http://code.google.com/p/chromium/issues/detail?id=118639#c145

------------------------------------------------------------------
r285108 | bcw...@chromium.org | 2014-07-24T02:12:51.186078Z

Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/content/public/android/javatests/src/org/chromium/content/browser/input/ImeTest.java?r1=285108&r2=285107&pathrev=285108
M
http://src.chromium.org/viewvc/chrome/trunk/src/content/public/android/java/src/org/chromium/content/browser/input/AdapterInputConnection.java?r1=285108&r2=285107&pathrev=285108
M
http://src.chromium.org/viewvc/chrome/trunk/src/content/public/android/java/src/org/chromium/content/browser/input/ImeAdapter.java?r1=285108&r2=285107&pathrev=285108

Send correct key-codes when doing composition events instead of always 0.

BUG=118639

Review URL: https://codereview.chromium.org/373523002

-----------------------------------------------------------------