Hi shuchen@, komatsu@,

Is this something you can help take a look?

Thanks.

I guess the root cause might be the “かな/英数” key isn't forwarded correctly to the host machine.

Maybe these lines are not executed:
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/input_method/input_method_manager_impl.cc?l=754-761

+afakhry@ who is familiar with accelerators.

This issue might be "certain accelerators fail to work in certain app, e.g. VMware Horizon Client".

Agnes, can you supply some more details? Is the issue that the input method isn't switching in the remote VM's OS, or that the input method isn't switching in the VMware Chrome app?

Do we have an internal Horizon View server that I can use to test this?

Is there any way to trigger it on a non-Japanese Chromebook? If not, I might not be the best choice for this bug unless someone can ship me one. :-)

Or is the problem that the Chromebook's local input method isn't switching when you press the language input key while the VMware app has the focus?

A broader question, since I've never seen a Japanese SKU's keyboard and don't know anything about this topic:

Which keys are actually present on the keyboard? I take it from the original report that we may have both かな and 英数 keys as in the Apple keyboard layout at https://en.wikipedia.org/wiki/Language_input_keys, but #2 points at code for handling Henkan and Muhenkan keys, which seem like separate keys that are used to switch between kana and kanji input.

Is the issue that ash/accelerators/accelerator_table.cc doesn't handle VKEY_HANJA and VKEY_KANJI?

Sorry, I know nothing. :-(

+Oshima for the rescue! :D

Re #6, yes.

Re #7, VKEY_CONVERT & VKEY_NONCONVERT.

Thanks! I'm not sure of the current state of how we determine which keys to handle locally vs. sending to the focused app, but do we always want to handle VKEY_CONVERT an VKEY_NONCONVERT locally, or will that cause issues with some apps that want them not being able to receive them?

Re #5, you can use an external physical keyboard (Japanese keyboard) on your chrome os device.

And I'm not sure whether this issue can repro with the on-screen keyboard, but it worths a try.
 - enable Japanese Keyboard (JA) and Japanese IME (あ) in the language settings.
 - activate JA
 - enable on-screen keyboard in A11y settings.
 - focus the VMWare app and pop up the OSK by click the keyboard icon on the tray area.
 - click かな key button on the OSK.
 - check whether the current input method is switched to あ.

According to the bug description, ctrl + space accelerator can work.

So I'd start to dig by putting break points at here:
https://cs.chromium.org/chromium/src/ash/common/accelerators/accelerator_controller.cc?l=789

And here:
https://cs.chromium.org/chromium/src/ash/common/accelerators/accelerator_controller.cc?l=804

Thanks!

The onscreen keyboard seems kind of broken (the browser crashed once when I clicked the "<" key to the right of the spacebar, and the keyboard layout never changes from DV even when I select "JA" from the menu to the left of the spacebar). Is there some additional extension I need to install or USE flag I need to set to convince it to display Japanese keycaps?

Otherwise, I'm happy to order a Japanese USB keyboard, if you can help recommend one (the options on Amazon seem limited).

Are you using an ARM Chromebook? The  issue 629593  is causing the OSK misbehaves.

No, this was on a EVT1 Samus.

So, any advice on where I can buy or otherwise acquire a keyboard that I can use to repro this?

I don't know where to buy a Japanese keyboard.

+yukawa@ +nona@ who may know a way to simulate the VKYE_CONVERT/VKEY_NONCONVERT.

> +yukawa@ +nona@ who may know a way to simulate the VKYE_CONVERT/VKEY_NONCONVERT.

Well, I do know how to simulate VKYE_CONVERT/VKEY_NONCONVERT on Windows but I suppose you want to simulate on Chrome OS, right?  If so, sorry, I don't know.

> Otherwise, I'm happy to order a Japanese USB keyboard, if you can help recommend one (the options on Amazon seem limited).

Probably any of the following ones should be OK to reproduce this issue.
 - https://www.amazon.com/dp/B002BKI8IS
 - https://www.amazon.com/dp/B002N886OY
 - https://www.amazon.com/dp/B01673RWZO

Thanks, I've ordered one!

Hi, I got some feedback from VMware vendor as below. Hope that will help for you.
----------------------------------------
The problem is caused by chrome OS’s enability to send any key sequence
when connecting virtual Desktop.

https://bugs.chromium.org/p/chromium/issues/detail?id=437386
https://bugs.chromium.org/p/chromium/issues/detail?id=625078


It could happen not only in view client but also in HTML access, both of which 
was triggered by Chrome’s ARC rum time.

View client does not receive the key sequence, that’s why it cannot send it and
consequently, Windows OS cannot respond to かな/英数key.

That’s why Vmware cannot do any action without Google’s action to deal with
Chrome/ARC’s runtime.
-----------------------------------

+kinaba@ in case this issue is related to ARC++/IME.

Let me reconfirm first; is this issue about
1) the key sequence does not switch the IME of Guest OS (Windows) inside VMware
or
2) the key sequence does not switch the IME of ChromeOS

#9 says yes to 2), but the whole thread looks talking about 1).
If this is about 1), it looks to be a raw key event handling issue rather than IME.

...and in that case, as far as dug the old ARC repository log, +Elijah looks to be the guy who implemented key event wiring.

Pepper API
https://chromium.googlesource.com/chromium/src/ppapi/+/master/api/pp_input_event.idl
takes Windows-style keycode, so my wild guess is that VKEY_CONVERT etc is wired up until this point,
but the ARC's framework impl treating the keycode simply as scancode (of qwerty keyboard) that may be causing mismatch.

Kyra (assuming you've starred the bug and are seeing this), can you try to get answers to the question in #22?

This is still blocked on getting more information (and on testing to see if it's still broken).

Sorry for really late reply.
Confirmed with our JP customer service, they haven't received any more feedback about this problem.
Since the date is long ago. We suggest this issue could be closed. 
thank you.

Thanks for following up!