If --site-per-process is not preset, clicking on the <input> in the other frame will lead to a change of TextInputState to none followed by text again. This will reset the IME since the RWHVAura (TextInputClient) will detach and reattached.

In case of OOPIF if we are in Widget A and click <input> in Widget B, the following two scenarios could happens (IPC received):

1- A: set to None => B: set to Text (Good)
2- B: set to Text => A: set to None (Not good, we still track the state correctly but the InputMethod does not really know that we might have changed the widgets).

What we should do is to detach and attach to InputMethod when we are switching widgets but not text type. For this, we should pass 1 more flag, like, |did_change_active_widghet| to TextInputManager::Observer::OnUpdateTextInputStateCalled. Then, in RWHVAura, if
widget has changed, we first call InputMethod::SetFocusedTextInputClient(nullptr). and then call it again with this (or something similar which will do the job).

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

commit 44c242985f1c9f81dc56e7d5122776250b1f1a66
Author: ekaramad <ekaramad@chromium.org>
Date: Wed Jul 27 21:17:29 2016

In TextInputManager, reset input type to none before switching active widgets.

When there are no OOPIFs in a page, if we switch focus from one <input>
into another (i.e., through a mouse click), the TextInputState will be
first set to NONE and then back to TEXT.

This however does not always happen when there are OOPIFs since the two IPCs might
arrive from different RenderWidgets and the order of arrival is not
deterministic (e.g., the IPC to set to TEXT could arrive sooner).

Although TextInputManager tracks the state and active widget correctly
(regardless of what order the IPCs arrive from the RenderWidgets), it
still does not mimic the exact same behavior as in the single
RenderWidget case. In Aura platforms, without setting the
TextInputState to none before changing the active widget, the IME
behavior might go wrong and InputMethod behave out of sync with the
actual TextInputState. The reason is that the InputMethod would believe
that the TextInputClient is the same but the IME session has ended.

This CL will try to simulate the same behavior for all scenarios by
injecting a TextInputState of none in between an active widget change.

BUG= 626171 , 578168 , 602723 

Review-Url: https://codereview.chromium.org/2171443003
Cr-Commit-Position: refs/heads/master@{#408239}

[modify] https://crrev.com/44c242985f1c9f81dc56e7d5122776250b1f1a66/chrome/browser/renderer_host/site_per_process_text_input_browsertest.cc
[modify] https://crrev.com/44c242985f1c9f81dc56e7d5122776250b1f1a66/content/browser/renderer_host/text_input_manager.cc

Is this one fixed now?

I believe it must be fixed as I myself cannot reproduce this anymore on ToT.