Remove logic to reset input method more than needed

content/browser/renderer_host/render_widget_host_view_aura.cc

Index: content/browser/renderer_host/render_widget_host_view_aura.cc
diff --git a/content/browser/renderer_host/render_widget_host_view_aura.cc b/content/browser/renderer_host/render_widget_host_view_aura.cc
index edb16bd7d4038cae87acdbd8598bc84efbfa3da3..4a67b6025fdb8b0109c361a15756df89f395c5a3 100644
--- a/content/browser/renderer_host/render_widget_host_view_aura.cc
+++ b/content/browser/renderer_host/render_widget_host_view_aura.cc
@@ -2981,6 +2981,12 @@ void RenderWidgetHostViewAura::OnUpdateTextInputStateCalled(
     last_active_widget->Send(new InputMsg_RequestCompositionUpdate(
         last_active_widget->GetRoutingID(), false /* immediate request */,
         true /* monitor request */));
+    if (has_composition_text_ && state->composition_start == -1) {

[aelias_OOO_until_Jul13, 2016/09/26 21:25:59]

Code in RenderWidgetHostViewAura only executes on Windows+Linux+ChromeOS, but
http://crbug.com/164427 is about Clank.

In general, I think code like this will be needed, before we add it, we should
have a test app that this fixes in order to sanity check that we're doing the
right thing (I assume you found google.com does not repro
http://crbug.com/164427 anymore nowadays even with the other deletions?)

If we cannot find a real-world example right now, we could try making an
artificial one, and/or land the Blink side of the change on dev channel and see
what breakage is reported to us.

[Changwan Ryu, 2016/09/27 03:00:12]

http://crbug.com/164427#c16
was the reason why it was originally implemented through cancelComposition(). I
can still reproduce the issue if I remove this logic.
You're right. It doesn't repro any more.
As for the other issue, I think a unit test should be enough.

[aelias_OOO_until_Jul13, 2016/09/27 04:39:47]

OK, understood, but the history (including the linked WebKit bug) shows this is
a totally artificial test case, and there's no evidence that any real-world
desktop JS forms rely on this.  In fact, the evidence cuts the other way because
the issue was preexisting before Aurimas noticed it while investigating an
Android issue.  Therefore I would prefer us not to go out of our way to add
extra lines of code to address this possible non-bug.  If there's a real issue
here, we'll hear about it in dev/beta channel and can always add these lines
then, with new confidence that they're useful.

+      // JS-triggered change caused composition to be lost.
+      // TODO(changwan): add a unit test.
+      GetInputMethod()->CancelComposition(this);
+      has_composition_text_ = false;
+    }
   } else {
     // Stop monitoring the composition information if the focused node is not
     // editable.