I am not convinced "VirtualKeyboard" is the correct component. This happens with the physical keyboard on my Pixelbook.

Also, found another particularly aggravating corner case. If I try to enter "€", I have to press Alt-Right, Capital-E, "=". The last keystroke in this sequence gets misinterpreted as a shortcut to (un)maximize the window. Apparently, even when Alt-Right is mapped to Compose, the window manager still traps Alt-Right-=.

I think, this is most likely all the same bug. But if you want me to open a new bug, just let me know.

UI>Input>Text>IME seems the right component.

+IME people

markus@, what keyboard layout were you using to repro this bug?

I am using "US Keyboard" and I have installed the "Compose Key" extension from the Chrome Store. I select "English US" as the layout. Does that help you reproduce the problem? If not, I can attach screen shots of the configuration dialogs. Would that help more?

I can repro the issue now. Glad to know there is a user of the IME API.

I will debug into the extension for the root cause.

Tried:

R68 10718.4.0, 68.0.3440.4 doesn't repro this issue.
R69 10748.0.0, 69.0.3448.0 doesn't repro this issue.

Over to zhangyu@ to help bisect.

Note: "Compose Key" is an IME extension published on the web store.

That is correct. After installing https://chrome.google.com/webstore/detail/composekey/iijdllfdmhbmlmnbcohgbfagfibpbgba and enabling the correct input method, the bug should be reproducible on 68.0.3440.4

If you don't have any luck reproducing, shoot me an e-mail and I'll see if I can get you better step-by-step instructions.

Fixing the typo in #8.

R68 10718.4.0, 68.0.3440.4 doesn't repro this issue.
R69 10748.0.0, 69.0.3448.0 repros this issue.

Please refer to the video recording for not repro on R68 dev:
https://drive.google.com/file/d/1R77FXRUnXhxI7inaBB-tBEH9gqx5NaiQ/view?usp=sharing

Just for the record. This is what chrome://version shows for me:

Chrome:   68.0.3440.4 (Official Build) dev (64-bit)
Platform: 10718.4.0 (Official Build) dev-channel eve

And I can still reproduce the problem as demonstrated here: E€=

You might not be getting good results from bi-secting, if you are under the impression that the bug doesn't repro in that version. I think it was probably introduced a little earlier.

Can you please try to repro this issue on another device (other than "eve") with the same version? Thanks!

markus@, can you please help on #13? Thanks.

I just tried on my son's original ASUS Flip:

  Google Chrome	68.0.3440.25 (Official Build) dev (32-bit)
  Revision	2ae8d1b3e748e1d64948045b2e1fb269a4098373-refs/branch-heads/3440@{#328}
  Platform	10718.22.0 (Official Build) dev-channel veyron_minnie
  Firmware Version	Google_Veyron_Minnie.6588.237.0
  ARC	4838043

The problem is reproducible on this machine. It is most obvious if you first press-and-release the compose key and then enter the two keys to be composed. If you press-and-hold the compose key and if you are careful to keep it pressed until you have completely entered the compose sequence, it is possible to avoid the issue. But that's different from all other platforms that have compose keys, and it's difficult to consistently do this while touch typing.

If you still can't reproduce the issue, I can probably give you access to one of my devices for testing for a few days.

That would be very helpful. markus@, please grant me access to a device that can repro the issue.

It is weird that this issue cannot repro on cros_sandbox on linux, but only repros on real device (e.g. kevin).
And I tried to deploy a local built chrome to kevin device, and issue is gone!

However, I encountered another issue on kevin + local-built-chrome, which is holding RightAlt and press "`" and "a" fails to input "à". I will fix that first.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c1bd75f2cab8d8d689f9effacbf88e4a2866f667

commit c1bd75f2cab8d8d689f9effacbf88e4a2866f667
Author: Shu Chen <shuchen@google.com>
Date: Thu Jul 05 09:13:30 2018

TextInputClient::InsertChar call after IME handled should use a purely faked key event.

Currently the fake key event is constructed from the native key event, which carries flags.
Therefore, InsertChar can be refused by TextInputClient, for example, when flags has ALT_DOWN.

Bug:  835699 
Change-Id: If29f61d18226091680ca3c900827fc3872b8b59d
Reviewed-on: https://chromium-review.googlesource.com/1126752
Reviewed-by: James Su <suzhe@chromium.org>
Commit-Queue: Shu Chen <shuchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#572742}
[modify] https://crrev.com/c1bd75f2cab8d8d689f9effacbf88e4a2866f667/ui/base/ime/input_method_chromeos.cc

This sometimes-repro-and-sometimes-not thing drives me crazy. :(

I start to suspect that when the issue repro'ed my account was included in xx% users for certain experiments, which cause the issue.

My guess is that something causes input.ime_custom_bindings.js doesn't work well.

+rdevlin.cronin@ for more ideas.

I'm not too familiar with the IME API, sorry.  The inpue.ime_custom_bindings.js file certainly has some issues (some of which are documented in issue 733825), but I'm not sure any would result in different/extra keys being generated.  I don't have any good ideas off the top of my head, but if there's anything specific I can help with, lemme know!

Devlin, I've sent u a cl to address issue 733825:
https://chromium-review.googlesource.com/c/chromium/src/+/1128780

FYI. the issue 733825 has been fixed.
Assuming this issue should have been fixed by the same cl.

The fix is included in M70 so pending on verification in R70 dev.

shuchen@ can you verify this now and close it if we're good?

markus@, mind verifying whether this issue can still repro on latest R70 beta/dev? Thanks!

I no longer see this problem on R70 (dev channel, Pixelbook)

Actually, I am lying and I take everything back that I said in comment 28.

Things seem to have gone from bad to worse for me. Initially, I simply upgraded to R70 and now R71, and everything was working beautifully.

But then I realized that I wasn't sure which version of the compose extension I am actually using with my account. So, I deleted the version from my device and re-installed it fresh from the web store. Afterwards, I cannot enter any composed characters. After pressing Alt-R, the next few keys are swallowed, but no new composed key is generated. That's even more disruptive than creating extra characters :-( So, no, I don't think the bug is fixed, unfortunately.

Let me know what I can help with.

shuchen is OOO, so I can take a look.

I can repro this issue on latest Compose Key extension (version 1.4) and Chrome (71.0.3560.0). First few characters are swallowed and the rest of the characters appear.

I'm assuming that nothing is meant to be visible when you are composing, but a character is meant to be inserted when you finish composing.

When I try to commit some text, it throws an error about invalid contexts, so I'll look into that.

Fix in progress: https://chromium-review.googlesource.com/c/chromium/src/+/1258702

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/54bf4f38c3ce27e4a90e1f4c4d6bf2f4bae1f56f

commit 54bf4f38c3ce27e4a90e1f4c4d6bf2f4bae1f56f
Author: Darren Shen <shend@chromium.org>
Date: Fri Oct 05 04:59:25 2018

[VK] Only send private onFocus to extensions that subscribe to it.

For the inline handwriting feature, we introduced a private onFocus
event to pass along stylus information. However, third party IMEs cannot
listen to this, so we have to dispatch the public onFocus events to
them.

In our original patch, we did consider this issue and made sure that
we only dispatch the private onFocus if "HasListener" is true. However,
it turns out that "HasListener" returns true if *any* extension is
listening to the event, so as long as the XKB extension is active,
no third party IMEs will receive the public onFocus event.

We change it so that we check whether each particular extension
is listening to the private onFocus event before dispatching, so that
the XKB extension receives the private onFocus event and third party
IMEs receive the public one.

We think that the other usages of HasListener are technicaly incorrect
as well, but we will fix them in a follow up patch to limit the scope
of this one.

TBR=shuchen@chromium.org

Bug:  835699 
Change-Id: I7895d8503eb3677de8d248475f2856d1dfd397ca
Reviewed-on: https://chromium-review.googlesource.com/c/1258702
Commit-Queue: Darren Shen <shend@chromium.org>
Reviewed-by: Leo Zhang <googleo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596998}
[modify] https://crrev.com/54bf4f38c3ce27e4a90e1f4c4d6bf2f4bae1f56f/chrome/browser/extensions/api/input_ime/input_ime_api.cc
[modify] https://crrev.com/54bf4f38c3ce27e4a90e1f4c4d6bf2f4bae1f56f/chrome/browser/extensions/api/input_ime/input_ime_api.h
[modify] https://crrev.com/54bf4f38c3ce27e4a90e1f4c4d6bf2f4bae1f56f/chrome/browser/extensions/api/input_ime/input_ime_api_chromeos.cc

Do we need to merge this? M70 is only one week away from stable. Since it seems this extension was broken since 67, I suggest we don't risk a merge? The fix will be in M71.

Just FYI, as mentioned in comment 29, this bug seems to have gotten much worse with 70. The previous situation wasn't great, but the Compose extension was (barely) usable in 67. It created bogus extra characters unless the user pressed the keys in a very precise order. It's completely borken in 70 as far as I can tell. It never creates any composed keys.

I don't understand enough about the root cause to tell whether this CL fixes the bug for good, or whether other fixes are needed. So, I can't make any recommendation on whether a merge would help users.

I see. This patch should fix the bug by itself. Let's try a merge then, since the extension went from hard to use -> completely unusable.

Requesting merge for c#33.

This bug requires manual review: We are only 10 days from stable.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

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

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f0b877f28755b8abe26eb8b5af653ad30be0dcef

commit f0b877f28755b8abe26eb8b5af653ad30be0dcef
Author: Darren Shen <shend@chromium.org>
Date: Mon Oct 08 02:38:56 2018

[Merge M70] Only send private onFocus to extensions that subscribe to it.

For the inline handwriting feature, we introduced a private onFocus
event to pass along stylus information. However, third party IMEs cannot
listen to this, so we have to dispatch the public onFocus events to
them.

In our original patch, we did consider this issue and made sure that
we only dispatch the private onFocus if "HasListener" is true. However,
it turns out that "HasListener" returns true if *any* extension is
listening to the event, so as long as the XKB extension is active,
no third party IMEs will receive the public onFocus event.

We change it so that we check whether each particular extension
is listening to the private onFocus event before dispatching, so that
the XKB extension receives the private onFocus event and third party
IMEs receive the public one.

We think that the other usages of HasListener are technicaly incorrect
as well, but we will fix them in a follow up patch to limit the scope
of this one.

TBR=shuchen@chromium.org

(cherry picked from commit 54bf4f38c3ce27e4a90e1f4c4d6bf2f4bae1f56f)

Bug:  835699 
Change-Id: I7895d8503eb3677de8d248475f2856d1dfd397ca
Reviewed-on: https://chromium-review.googlesource.com/c/1258702
Commit-Queue: Darren Shen <shend@chromium.org>
Reviewed-by: Leo Zhang <googleo@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#596998}
Reviewed-on: https://chromium-review.googlesource.com/c/1267755
Reviewed-by: Darren Shen <shend@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#886}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/f0b877f28755b8abe26eb8b5af653ad30be0dcef/chrome/browser/extensions/api/input_ime/input_ime_api.cc
[modify] https://crrev.com/f0b877f28755b8abe26eb8b5af653ad30be0dcef/chrome/browser/extensions/api/input_ime/input_ime_api.h
[modify] https://crrev.com/f0b877f28755b8abe26eb8b5af653ad30be0dcef/chrome/browser/extensions/api/input_ime/input_ime_api_chromeos.cc

The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/f0b877f28755b8abe26eb8b5af653ad30be0dcef

Commit: f0b877f28755b8abe26eb8b5af653ad30be0dcef
Author: shend@chromium.org
Commiter: shend@chromium.org
Date: 2018-10-08 02:38:56 +0000 UTC

[Merge M70] Only send private onFocus to extensions that subscribe to it.

For the inline handwriting feature, we introduced a private onFocus
event to pass along stylus information. However, third party IMEs cannot
listen to this, so we have to dispatch the public onFocus events to
them.

In our original patch, we did consider this issue and made sure that
we only dispatch the private onFocus if "HasListener" is true. However,
it turns out that "HasListener" returns true if *any* extension is
listening to the event, so as long as the XKB extension is active,
no third party IMEs will receive the public onFocus event.

We change it so that we check whether each particular extension
is listening to the private onFocus event before dispatching, so that
the XKB extension receives the private onFocus event and third party
IMEs receive the public one.

We think that the other usages of HasListener are technicaly incorrect
as well, but we will fix them in a follow up patch to limit the scope
of this one.

TBR=shuchen@chromium.org

(cherry picked from commit 54bf4f38c3ce27e4a90e1f4c4d6bf2f4bae1f56f)

Bug:  835699 
Change-Id: I7895d8503eb3677de8d248475f2856d1dfd397ca
Reviewed-on: https://chromium-review.googlesource.com/c/1258702
Commit-Queue: Darren Shen <shend@chromium.org>
Reviewed-by: Leo Zhang <googleo@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#596998}
Reviewed-on: https://chromium-review.googlesource.com/c/1267755
Reviewed-by: Darren Shen <shend@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#886}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}

markus@, the R70 beta which contains the fix has just been released.

Can you please verify whether the issue you mentioned in #35 has fixed? And what about this issue overall?
Thanks!

My Pixelbook is on the dev channel and thus runs 71.0.3572.0. I am pretty sure, it also just received the bug fix. And yes, things are now working perfectly again.

I even tried removing the extension and re-installing from the web store. And yes, it does what it is supposed to do, now. µäöü€

Thanks for helping to verify. Closing this issue then.