@lennart.borgman: Thanks for the report!!

Could you please help us with the sample file where are you're seeing this issue, details of your device, if possible attach a screencast as well for triaging the issue?

Thanks!!

Hi @sandeepkumars,

I realized there is a much easier way to do this than my test files. Just use this:

// https://w3c.github.io/uievents/tools/key-event-viewer.html
//
// To setup for testing contenteditable edit the input element like this:
//
// <span id="input" contenteditable="true" size="80" autofocus="" style="display:inline-block; height: 20px; width:100px; border:2px solid red; background:#ccf"></span> <b>Contenteditable!</b>

I don't have things setup for mobile debugging, but I guess you have. 

I am using Motorola Moto G5 when I see this, updated to Android 7.0 (with the latest available security patch applied, of course).

And since you are in the position to do this, please contact the maintainers of the W3C test tool above to allow for testing "contenteditable". I think if it were already there I might not have needed to run this test.

There is another thing here too: A possible security problem. Please look at the output for the "beforeinput". It is a bit random and that does not feel good at all since Gboard run with high privileges.

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please add a security label to this issue. (I see no formal way to indicate this now. Wasn't that possible before?)

Tried the issue using #64.0.3282.137  on Android 7.0.0 Samsung J7 with the attached html page but still couldn't reproduce the issue.

@lennart: Could you please help us with a screencast for better understanding of the issue.

Thanks!!

I'm trying to pin down the problem, but it is not easy. What I see is that something is stochastic. But I'm not sure what since I do not have a simple test case where I see this.

Here is what I am seeing now:

I hacked the w3c keyboard event viewer to optionally use a contenteditable input element. To my disappointment the problem doesn't show up there. Or at least I haven't seen it there so far.

However I can rather easily reproduce it in an example made from my original code. But not always, it is intermittent.

If I switch to SwiftKey everything works as I expect it to do.

(I see some very strange things with Gboard, but those might be some timing problems, race problems. Though if it is that kind of problem and it depends on something in my JavaScript code I would expect to see it when using SwiftKey too, but I don't.)

I'll dig a bit more.

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I still do not understand exactly what is happening, but I can now safely reproduce the example with a small example with the mobile I mentioned earlier.

What at the moment confuses me most is that I can't reproduce the problem with the modified version of the W3C Keyboard Event Viewer.

I attach two files that I use to reproduce the problem. Just open the html file in a mobile and click on Enter in Gboard. 

Things like this can happen:

1) It can work. You will see "ev.key: Enter" etc.

2) You can get three events with "ev.key: Unidentified, ev.keyCode: 229" etc.

3) A mix of those.

Tapping on the delete key above Enter might help. o.O

Deleted: test.html 1.0 KB

test.html 1.0 KB View Download

Deleted: test-mobile-edit.js 2.2 KB

test-mobile-edit.js 2.2 KB View Download

Tried the issue using #64.0.3282.137 on Android 7.0.0 Samsung J7 with the attached html page in comment #10 but still couldn't reproduce the issue.

@lennart: Could you please help us with a screencast for better understanding of the issue.

Thanks!!

I uploaded the test with a slight different layout to the web. Here is an example of what I see.

Deleted: Screenshot_20180208-180455.png 213 KB

	Screenshot_20180208-180455.png 213 KB View Download

That was after clicking Enter, of course.

I just reloaded the page and tried again. This time it worked as it should.

Deleted: Screenshot_20180208-180913.png 133 KB

	Screenshot_20180208-180913.png 133 KB View Download

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I then continued by clicking on the content editable field again (to bring up Gboard). I then hit "l" a few times and then Enter.

The l:s all were inserted as they should. However the log they are "Unidentified, 229".

I think the final Enter produced three events: 229, 13, 229.

Deleted: Screenshot_20180208-181855.png 214 KB

	Screenshot_20180208-181855.png 214 KB View Download

Worth noting here is perhaps that my mobile (Motorola Moto G5) is just clean Android with just the nessary changes (HAL, so to say).

To me the bug looks like bad or corrupt memory pointers. And therefore a possible security problem, as i said before.

You can't really use key event listeners with Android because the model of input it uses is composition. What you are likely seeing is that if you are in a composition and press enter it ends up generating a 229 (compose key code).

Chrome is subject to the calls that the IME (gboard or swiftkey make here). We turn those into composition events. 

You might want to look at: https://developer.mozilla.org/en-US/docs/Web/Events/compositionupdate

Thanks @dtapu, I didn't know that. So that explains the 229 - for single characters.

However the part I'm most interested in here is the Enter key. In SwiftKey that is always found as event.key === "Enter". And no strange things happen.

In Gboard sometimes the same things happen. But the things I sent above may also happen. And position of the caret might change I believe. 

But for me the blocking part is the handling of the Enter key. You simply can't use Gboard in many cases because of this.

Thank you for providing more feedback. Adding requester "dtapuska@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I just got confirmed that the strange behavior I see happens in another mobile.

That mobile is also a Motorola Moto, but the older G3.

I don't know if you noticed, but clicking Enter sometimes leads to insertion of a number of various characters in the content editable field. (This was also confirmed on the other mobile.)

I have noticed they seem to be copied from the field but i have no idea if they are restricted to that.

Looking at this with my slightly modified version of the W3C Keyboard Event Viewer the following can happen (with Gboard in content editable)

1) clicking Enter results in just the "keydown" sequence.

2) however if some characters are inserted in the field and the caret is placed before some of them then suddenly also the "composition start" sequence also appears when clicking Enter. (This doesn't happen with SwiftKey.)

Right and these events you are seeing are results of the APIs that the keyboards are calling. There is nothing we can do to know what input they are providing us. We basically mirror their calls to javascript events. I'm not sure what you want us to do.

Thanks @dtapu. So you suggest the bug is in Gboard? I think so too. Didn't I ask in the start where I could report this? How do I proceed?

I don't think it is an error in gboard either. Those keyboards just produce different states that are valid.

@dtapu
I don't believe you have read this. You can't seriously mean that it is ok for Gboard to insert random content in a contenteditable field.

If you are seeing strange characters inserted into a content editable then that certainly is an issue. But I haven't seen that in any of the screenshots provided.

The fact that you are seeing keyboard events with "Unidentified/229" just indicates whether enter was pressed inside a composition or not. If it isn't inside a composition then gboard is producing the "Enter" as you are expecting. But when it is inside a composition then it is probably turning that into a compose text message and we generate a 229 for that.

Can you provide a screenshot of the random text inserted?

@dtapu
Oh, sorry. I just wrote that it happened. Here is one image I got from a user. I can reproduce the same myself, but I happen to have this here now.

The user clicked Enter several times then the caret was right after "conten" and the word was still "contenteditable". No other key was clicked than Enter.

Deleted: chars-inserted-on-enter.png 191 KB

	chars-inserted-on-enter.png 191 KB View Download

Over to the Blink>Editing team for them to take a look at maybe they can understand what you are describing as I'm still unclear. Perhaps a video might help us understand the incorrect behavior.

@dtapu
Any good tool for creating such a video on my mobile?

#31: use "adb shell screenrecord filename"

It looks for me, that this bug is very similar to bug in Android WPS Office bug (it seems to happen in WebView and only with GBoard).

1. In WPS Office create doc with two lines:

a
b

2. save it

3.put cursor before b

4.press BackSpace, you will get

ab

5. write x, you will get

axb

6. press enter -> you will get

ax

but... b is deleted

Here is a video showing the problem.

https://youtu.be/vBzBX5hqQgc

Thanks @mar.
In my case this bug totally blocks what I want to do. So I hope Google will fix it. When did you discover this problem?

Tried using #64.0.3282.137 on Android 7.0.0 Samsung J7 as per the steps followed in the attached video and still couldn't reproduce the issue.

@lennart: Could you please find the attached video and also let us know on which device you're facing this issue?

Thanks!!

Deleted: 809107.mp4 4.1 MB

	809107.mp4 4.1 MB View Download

Thanks @sandeepkumars. I took a look at your video. Please avoid spaces. It is much easier to see what happens without them.

To make it a bit easier for you to test I have uploaded my modified version of the W3C Keyboard Event Viewer here: https://goo.gl/WXfWBA

To test please follow this instructions:

1) Open the page above in your mobile
2) Click "Show Options"
3) Check "preventDefault / keydown"
4) Click "Hide Options"
5) To get the caret position at 3 again, click the green "Input text" and then the red "Contenteditable"
6) Now just click Enter in Gboard. Several times. Maybe different speeds.

Nothing should happen in the input field, but for me it does. First there is a line break (actually <br>) and then it starts to enter "d" + plus the position changes to after the inserted "d":s.

Do you see something similar? Please otherwise show me a video of what happens when you try this.

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Oh, yes, once again: I am using a Motorola Moto G5.

I followed the instructions. Did not work. Have one plus 5. 

Deleted: Screenshot_20180209-150238.jpg 484 KB

	Screenshot_20180209-150238.jpg 484 KB View Download

Followed the instructions. Phone model Samsung Galaxy s8

Deleted: SmartSelectImage_2018-02-09-15-09-13.png 448 KB

	SmartSelectImage_2018-02-09-15-09-13.png 448 KB View Download

A short summary. On every mobile that I know has been tested the bug shows up.

This includes the mobile tested in the video posted by @sandeepkumars above. 

Maybe you don't understand what you see there? Then please ask me.

To avoid more confusion I went up to my technical university (LTH, Lund, Sweden) and asked some students there to test on their mobiles. The result from two of those were posted above. (Many thanks to those who helped me test.)

So now we know that the bug shows up on at least those mobiles:

- Motorola Moto G5 
- dito G3
- Samsung J7
- Samsung Galaxy S8-
- One Plus 5

Could you now please connect me to the people who understand and can fix the bug?

Note that we do currently special-case an IME calling commitText() with just a newline and fire a keydown event with KEYCODE_ENTER in this case:
https://chromium.googlesource.com/chromium/src/+/b980ed84f34f79b56a29a6f5bf28064744037c3f/content/public/android/java/src/org/chromium/content/browser/input/ThreadedInputConnection.java#327

However, that’s just a hack we decided to addf for one specific case; we generally don’t like to create “fake” key events based from IME commands.

If there are separate issues you’re running into, please file them separately.

Mark WontFix since IMEs don't need to send keyboard event.

Please use "beforeinput" event[1] with "insertParagraph" command to handle
Enter key as hardware keyboard.


[1] https://www.w3.org/TR/input-events-1/

yosin@, could you comment also #32? It's another example, when GBoard doesn't work and other keyboards work fine.

We have also https://bugs.chromium.org/p/chromium/issues/detail?id=118639 opened in Mar 2012.

Something is definitely wrong here

Please reopen this yosin@. You are misunderstanding. The main issue here is that event.preventDefault() does not work and leads to insertion of characters etc when Enter is clicked in Gboard. 

It will not help to use "beforeinput" because of this.

You never mentioned preventDefault until Comment 37. Your original bug report merely said the “input event” (but I think you were referring to “keydown” and “beforeinput”?) is “useless.” So we’re getting confused about what you’re asking for here.

Unfortunately we do not currently support canceling IME commands due to concerns about the keyboard becoming out-of-sync with the webpage.

For context, see this document, specifically the “Reasoning” section under “2 Make IME input types noncancelable”:

https://docs.google.com/document/d/1yPZEkHl_WOPjVeilZjE1XmlyjLCe-uS7THI0SboyrMM/

rlanday@, yes, I did not mention ev.preventDefault() until later. Simply because I did not understand at all what was happning. The output I saw was just too confusing. (However preventDefault is in the code in #10. At that point it was clear to me.)

First the bug (as I see it as a JavaScript developer):

1. preventDefault does not really stop the default behaviour.
2. but it changes it. 
3. Various characters may be inserted
4. And position may change

More about that later.

Thanks for the pointer to the discussion about the emerging standards. Especially the part about the CKEditor is very enlightening. I welcome your suggestions about getTargetRanges() in "beforeinput" and "input". I will definitively need something like those too. (But please do not forget to sync those things with undo/redo.)

However I am not sure this is on the right logical level from a JavaScript developers side. An example: You may need to keep track of identifiers, classes etc when inserting and deleting. (This is something I need. And I expect it is not to uncommon. And it must be coordinated with the browsers view, of course.)

CKEditor may not have that kind of need. (I have not looked into it. I try to just stay as close to standards as possible.)

Regarding the ability to use ev.preventDefault() for "keydown" to stop all default behaviour I can't see why you do not support it. I mean for clicking a key on a virtual keyboard. 

I can certainly see that in more complicated cases you just need standards to know what to implement.

But in the case "the user just clicked something that is similar to typing a single key on a desktop" you can handle it. You clearly recognize this behavior from the user so it should not be much job to just stop the default behavior (and do nothing).

If you do this it is much, much easier for a JavaScript developer to write code for both the desktop and mobiles. And that is really what you want, isn't it? ;-)



 

Thanks rlanday@ for adjusting discussion direction.

lennart.borgman@, please file an issue in [1] for your proposal of programming
model of editing with IME.

crbug.com is a place for Chromium specific issue. It seems you propose brand new concept.

We, Chromium devs, thinks MVC is current and feasible solution for IME handling since
all OS's don't allow canceling IME composition at this time.

Keyboard is one of interface of IME. IME handles voice, hand writing, camera (character recognition), 
signals in brain etc. So, cancling IME composition from keyboard is not enough.


BTW, even on desktop IME, preventing default for keydown doesn't stop IME composition:
https://jsfiddle.net/0xqL52q1/1/

W3C IME API[2] is one of the steps to allow IME composition cancelation however no
vendoers are interested in.


[1] https://github.com/w3c/editing/issues
[2] https://www.w3.org/TR/ime-api/

First let me say that you, Chromium devs, are doing a wonderful job with Chrome. It is certainly one of the most complicated apps I can think of. (And handling CSS must take a lot of patience.) It has been a pleasure to see your efforts in stabilizing Chrome and it saves people like me a lot of time.

Now that I know that event.preventDefault() is not supposed to work things get much more clear.

Taking a quick look at W3C and the output from my modified keyboard event viewer it looks to me that there are no technical reason that you can't stop all default behavior at "keydown" when clicking a single key. You can for example distinguish easily between glide typing and clicking on a single key with the information you have at the first "keydown" now.

However there may of course be logical reasons you do not want to stop all default behavior at "keydown" that way because it would interfere with composition of characters not on the virtual keyboard. 

I first thought that the later reason, the logical reason, might apply to all keyboard keys, but as far as I can see it probably does not apply to the Enter key.

Why do I guess this? Because that key is also used for ending input for example when searching.

And this a bit similar to what I need. In my case I want to end the user input and in the background submit data to a database. In my case there is no good place to add a submit button. 

When it comes to search input the virtual keyboards seems to recognize <input type="search">. There is no such thing available in my case, unfortunately.

It looks to me that the people behind Swiftkey has realized that the Enter key is a bit special so they have made it possible to use event.preventDefault() for the Enter key at "keydown". It would be nice if you did this too.

So I suggest the following:

1) Allow event.preventDefault() for Enter in Gboard.
2) Set the relevant fields (keyCode and key) for Enter.
3) Throw an error if event.preventDefault() is called for other keyboard keys (or compositions). Since what happens there now is just a mess.

> Taking a quick look at W3C and the output from my modified keyboard event viewer it looks to me that there are no technical reason that you can't stop all default behavior at "keydown" when clicking a single key.

It might be possible. But basically what we would have to do is reset the IME state after an IME command is preventdefaulted, since IMEs typically don’t actually have an API to tell them an app or web page is rejecting a command. We don’t think this is generally a safe thing to do, since IMEs probably aren’t written to support it properly.

> You can for example distinguish easily between glide typing and clicking on a single key with the information you have at the first "keydown" now.

The only way we have of determining this is how many letters are being changed at a time. For example, if an IME opens a composition with the text “t”, and then changes it to “th” and then “the”, we could guess that the user is typing one letter at a time. But they could also e.g. be using voice input and saying “type the letter t”, “type the letter h”, and so on. So we prefer to just pass the information along to web developers and let them decide what to do with it.

> It looks to me that the people behind Swiftkey has realized that the Enter key is a bit special so they have made it possible to use event.preventDefault() for the Enter key at "keydown".

We added a hack in Chrome that maps IMEs calling commitText("\n") to an "enter" keypress to work around an issue in a Google app that uses WebView ( https://crbug.com/577967 ). I don’t like this hack since it’s inconsistent with our general philosophy for handling IME key presses, but there’s some risk to changing it at this point. Swift is probably sending this command when you hit "enter". Or, maybe it’s actually sending a key press event instead of an IME command. Gboard seems to use more complicated sequences of commands than some other keyboard apps, so it may behave differently.

For your suggestions:

1) We don’t think it’s generally a good idea to fix problems by requesting that Gboard change its behavior, because not everyone uses Gboard. We like to fix problems in a way that works with other IMEs as well.

2) We don’t generally like to try to map IME commands to keypress events. I know we already have the hack I mentioned, but we can’t really tell the difference between someone hitting “enter” on a virtual keyboard (unless the keyboard explicitly sends us a key event, like a physical keyboard would; most virtual keyboards do not) and someone speaking “new line” to a voice IME. As far as I’m aware, native Android apps use basically the same API that Chrome is providing web developers.

3) We have a bug open to mark the synthetic 229 keydown/keyup events as non-cancelable in JavaScript ( https://crbug.com/737349 ). This unfortunately requires some refactoring that we probably won’t get to for a while.

Can be done something with #32 and https://bugs.chromium.org/p/chromium/issues/detail?id=118639 too?

I don’t know anything about WPS Office, so I don’t know what’s causing that bug.

Our opinion on  https://crbug.com/118639  hasn’t changed since aelias@'s most recent comment:
https://bugs.chromium.org/p/chromium/issues/detail?id=118639#c272

rlanday@, thank you for your comment.

WPS Office - we seems to speak about WebView issue, which is propagating to this app

118639 - can Chrome display own keyboard in such cases? It will be better than nothing.

If you can reproduce the WPS Office bug in a contenteditable element in Chrome (e.g. <div contenteditable></div>), please file it as a new bug.

118639: Chrome doesn’t have our own Android keyboard and we’re probably not going to build one. We think it’s important to our users that they be able to choose what keyboard they want to use.