It's a bit misleading that it "works in other browser" as it doesn't really apply.

Able to reproduce the issue on Windows 10 using chrome reported version #58.0.3029.96 and latest canary #60.0.3099.0 .
Issue in not reproducible on OS-Linux and OS-Mac.

Bisect Information:
=====================
Good build: 55.0.2860.0    Revision(418438)
Bad Build : 55.0.2861.0    Revision(418732)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/d4f486c125772068950e8e43e3805dcf74eb23f5..87b8f7c3fc3e5bbcc9601023df0fe79cb79234e8

From the above change log suspecting below change
Review url: https://codereview.chromium.org/2339793002

aelias@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

Blink CommitText("") semantics changed in that patch to delete text instead of passively canceling the composition.  My initial guess is <webview> IME has some special codepath so that it's not affected by the 'if (!text.length()) finishComposingText()' added in render_widget_host_view_aura.cc to compensate.

I'm not sure how <webview> IME is plumbed through.  wjmaclean@, could you explain the classes/objects it flows through from the browser to Blink?

ekaramad@ is the expert on this, adding them.

First off, this issue only occurs on <webview> based on BrowserPlugin. The bug is fixed in the new <webview> roll-out (hopefully in M60). To try it sooner you can enable the "Cross process frames for guests" flag in chrome://flags.

I am not yet quite sure about the BrowserPlugin-based case. to answer comment #4, we send all InputMsg IPCs including the IME ones to the embedder which then goes to BrowserPlugin (WebPlugin). BrowserPlugin sends IPCs to BrowserPluginGuest which will finally send them to RenderWidget of the second (<webview>'s) renderer.

While taking a look at this bug I noticed another bug we have with aura which is calling ImeFinishComposingText twice in response to the mouse click. The reason is that we first call this in RenderWidgetHostViewInputHandler and then call ImeCancelComposition before setting |has_composing_text_| to false which ends up sending another IPC.

I will keep poking at this and update the bug.

OK, thanks for the update.  Marking this blocked on OOPIF webview bug, then.  Since this has been broken since M55 it's probably OK to wait until M60.

comment #7: Agreed. The bug has been out there for a while.

I also found a fix for the bug and will upload the CL soon. The underlying issue was that the IPC BrowserPluginHostMsg_ImeFinishComposingText does not have a field for browser plugin instance ID so the chain is broken at the embedder to browser link.

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

commit f035886ce3dc15b321f1cd7d0c64948e552e53cc
Author: ekaramad <ekaramad@chromium.org>
Date: Tue May 23 18:10:13 2017

Fix an IME regression for <webview> due to missing IPC message param

The IPC message BrowserPluginHostMsg_ImeFinishComposingText does not have a
parameter for the instance ID of BrowserPlugin and therefore, is dropped on
the browser side inside BrowserPluginMessageFilter. This causes a regression
in (Japanese) IME where clicking during an ongoing composition does not commit.

BUG= 720023 

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

[modify] https://crrev.com/f035886ce3dc15b321f1cd7d0c64948e552e53cc/content/browser/browser_plugin/browser_plugin_guest.cc
[modify] https://crrev.com/f035886ce3dc15b321f1cd7d0c64948e552e53cc/content/browser/browser_plugin/browser_plugin_guest.h
[modify] https://crrev.com/f035886ce3dc15b321f1cd7d0c64948e552e53cc/content/common/browser_plugin/browser_plugin_messages.h
[modify] https://crrev.com/f035886ce3dc15b321f1cd7d0c64948e552e53cc/content/renderer/browser_plugin/browser_plugin.cc

Tested the issue on Ubuntu 14.04 & Windows 7 using chrome dev version#60.0.3112.7 with the steps mentioned in comment #0.Observed that the text stays and gets committed in the text box when user type any text in Japanese (Mozc) language.Text is not getting disappeared when we click on text box or outside the text box. Hence adding TE-Verified labels.

Please find the attached screen cast for the same.
Thanks!!

Deleted: 720023.ogv 3.3 MB

	720023.ogv 3.3 MB View Download

I've tried the patch and it's working nicely. Thanks for taking the time on this!