Well, the error seems to be coming from [1]. I'm not sure why there would be no engine...

[1] https://cs.chromium.org/chromium/src/chrome/browser/extensions/api/input_ime/input_ime_api.cc?q=inputimesendkeyeventsfunction&sq=package:chromium&l=370

Hi Shu, do you know why there might not be an input method engine?

There should be always an engine, but not always an active engine.

The active engine is got from here: https://cs.chromium.org/chromium/src/chrome/browser/extensions/api/input_ime/input_ime_api_chromeos.cc?gsn=GetActiveEngine&l=410.

Somehow InputMethodEngineBase::Enable() is not called appropriately in InputMethodManagerImpl::ChangeInputMethodInternal().

My intuition is it may be related to profile stuff.

This bug happened again. Based on Shu's comment in #7, could it be caused by having multiple profiles and switching between them?

When I rebooted and logged out of my multiple profiles and only used mine,
the bug went away.

David also encountered the same issue. He also uses multiple profiles. I might spend some time to investigate this.

I also encountered the bug randomly with multiple profiles. I've uploaded a custom build with extra logging to my test device, but wasn't able to reproduce since. I'll update the bug when I run into the issue again.

Ran into the bug again (while filing a bug for something). It was on a custom build with some logging:


[27847:27847:0618/155918.674594:ERROR:input_ime_api.cc(374)] SendKey
[27847:27847:0618/155918.674639:ERROR:input_ime_api.cc(375)]  Getting event_engine from profile: 0x3b1e7660ac80
[27847:27847:0618/155918.674654:ERROR:input_ime_api.cc(379)]  Got event_router: 0x3b1e7699de80
[27847:27847:0618/155918.674665:ERROR:input_ime_api.cc(380)]  Getting engine from event_router: jkghodnilhceideoidjikpgommlajknk
[27847:27847:0618/155918.674676:ERROR:input_ime_api_chromeos.cc(459)] GetActiveEngine: jkghodnilhceideoidjikpgommlajknk
[27847:27847:0618/155918.674686:ERROR:input_ime_api_chromeos.cc(462)] Contents of the engine map: 
[27847:27847:0618/155918.674696:ERROR:input_ime_api_chromeos.cc(464)]  jkghodnilhceideoidjikpgommlajknk: 0x3b1e77d38600
[27847:27847:0618/155918.674707:ERROR:input_ime_api_chromeos.cc(466)] found engine? 1
[27847:27847:0618/155918.674717:ERROR:input_ime_api_chromeos.cc(468)] is active? 0
[27847:27847:0618/155918.674728:ERROR:input_ime_api.cc(383)] engine: (nil)


Kinda annoying that I didn't log places where an engine could be deactivated...but at least we know that the engine is there, but inactive.

Encountered the bug again. Definitely something to do with multiple profiles. What's happening is:

1) Chrome post profile init is calling SetState on a profile.
2) We get the current IME handler and disable it.
3) We try to get the IME handler of the new profile, but it's not been registered yet.
4) We can't enable it, so we use fallback keyboard.
5) We later enable the IME handler for the new profile.
6) **When we SendKey, we get the IME handler from step 2), which is disabled**

A bit confused here as to why we get the disabled IME handler in step 6), but looks suspiciously like a race condition. I'll add more detailed logging and try to reproduce it.

Okay, I think I have a reliable repro:

1) Start from fresh.
2) Login to profile A.
3) Use "add new account" to (multi)login to profile B.
4) Switch back to profile A.
5) Go to chrome://flags and change a flag.
6) Click the "Relaunch now" button.

The timeline that I'm getting from the traces is:

1) We register the IME extension in InputImeEventRouter::RegisterImeExtension
2) We call InputMethodManagerImpl::StateImpl::AddInputMethodExtension on profile A.
3) Now profile A has a working & enabled IME engine handler.
4) We call Preferences::Init with profile B (why?)
5) We disable the current engine handler (profile A's engine)
6) We can't enable profile B's handler because it hasn't been added.
7) We use the fallback keyboard (this doesn't seem to work though, we get stuck in the non-fallback keyboard).
8) SendKey fails because the engine is disabled.

Thanks shend@ for the investigation. I start to work on this issue this week.

I attached a screenshot of chrome://inspect when I hit a similar looking issue. Can you verify if it is the same?

Thanks!

Deleted: Screenshot 2018-06-24 at 9.09.25 PM.png 947 KB

	Screenshot 2018-06-24 at 9.09.25 PM.png 947 KB View Download

Yeah that looks like the same bug. Thanks for reporting :)

I tried my best to guess the root cause based on the debug logs, and create a quick fix cl https://chromium-review.googlesource.com/c/chromium/src/+/1114561.
Needs to confirm whether it can fix the issue. shend@ will help on it.

With shend@'s help, I hunted the root cause. When 2 users (say, A & B) are logged in, and browser restarts, preferences of A and B are initialized.
However, InputMethodManager is singleton which represents the current input method listing state for current active user. But Preferences::Init() tries to call InputMethodManager::SetState() no matter of whether the Preferences instance belongs to an active user.
Therefore, these would happen:
1) User A: InputMethodManager::SetState(), IMEBridge::engine_handler_=null.
2) User A: InputMethodManager::AddInputMethodExtension(), IMEBridge::engine_handler_=engineA; engineA->Enable().
3) User B: InputMethodManager::SetState(), engineA->Disable(); IMEBridge::engine_handler_=null.
4) User B: InputMethodManager::AddInputMethodExtension(), engineB->Enable().
Now for the active user A, the state becomes to IMEBridge::engine_handler_=null; engineA is disabled.

The API implementation on ChromeOS: https://cs.chromium.org/chromium/src/chrome/browser/extensions/api/input_ime/input_ime_api_chromeos.cc?l=447
So when SendKeyEvents API is called, it will not get the engine from IMEBridge but from its internal engine map.
However, engineA is disabled. SendKeyEvents fails.

The fix is on the way.

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

commit 8e53e8ede7255859583e1e0b82768c8b210dcf42
Author: Shu Chen <shuchen@google.com>
Date: Tue Jul 10 01:56:41 2018

The init of Preferences instance should affect the singleton InputMethodManager state only when the preferences belongs to the active user.

Bug:  841112 
Change-Id: I7ed3cb2cbd8c0a27cab869f336c93c1a5becefa6
Reviewed-on: https://chromium-review.googlesource.com/1125646
Commit-Queue: Shu Chen <shuchen@chromium.org>
Reviewed-by: James Cook <jamescook@chromium.org>
Cr-Commit-Position: refs/heads/master@{#573595}
[modify] https://crrev.com/8e53e8ede7255859583e1e0b82768c8b210dcf42/chrome/browser/chromeos/preferences.cc