Bisec lead to this change:
https://chromium.googlesource.com/chromium/src/+/fa291796686fef74a48f18061b9e36ccc9488a06

I build Chrome locally at branch location of CL above and after reverting it the issue was resolved.

Assigning to the owner for investigation.

nona@: Could you please take a look?

Since this seems a regression for M-54 I set it to Pri-1. Feel free to change as appropriate.

Sorry I haven't noticed. Will take a look soon.

 Issue 640012  has been merged into this issue.

Looks like not reproducible with Linux+mozc, please give a some time. I need to set up OSX for chromium development.

Thanks nona@!

I poked at it and noticed that setting |monitor_composition_info_| to true in RenderWidget constructor (for Mac) seems to have fixed the issue. But I am not quite certain if that is the right fix.

Was this change for composition updates only targeted at Aura?

According to  Issue 640012 , this is also affecting Windows and Chrome OS.

ping?  If it is unlikely that we can figure out a safe way to fix this issue, I'd recommend reverting https://codereview.chromium.org/2121953002 as soon as possible, before someone starts depending on that change.

54 is not yet in beta so we still have a bit of time on this before there's a risk of the bug sticking, but marking RBS to make sure it's not forgotten.

If it turns out to be due to my request in codereview to avoid platform ifdefs, ideally I'd like us to stick to the current approach and fix the problem directly, but as a quick fix I'd also tolerate a runtime setting.

Removing Windows and Chrome OS labels as  Issue 640012  was unduped from this.  Let's use this issue for Mac, and use  Issue 640012  for Windows/Chrome OS.

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

commit fbd66b59cd50bacb823d7aeb6396f32594583fb1
Author: nona <nona@chromium.org>
Date: Mon Sep 12 06:10:39 2016

Fix the wrong candidate window on Mac OSX.

After http://crrev.com/dac0c7af14c29c9d8509b775d5044e5448b6263b,
renderer no longer capturing the composition bounds by default.
To receive the latest composition bounds from renderer, we need to
update the monitor state and it was done for aura platform in above
CL. This CL introduces the similar logic to RWHVM to fix the wrong
candidate window issue.

BUG= 639552 

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

[modify] https://crrev.com/fbd66b59cd50bacb823d7aeb6396f32594583fb1/content/browser/renderer_host/render_widget_host_view_mac.mm

Verified this issue on Mac 10.11.6 using chrome dev version #55.0.2859.0 and observed that the fix is working as expected.

Attaching screencast for reference.

Hence, adding the verified labels.

Deleted: 639552.mp4 696 KB

	639552.mp4 696 KB View Download

Thank you for verifying the issue.
Let me request the merge for the M54.

Your change meets the bar and is auto-approved for M54 (branch: 2840)

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

commit 3c0e829d4ed12936c68a34ec918acaf4d9f7c0ef
Author: Seigo Nonaka <nona@google.com>
Date: Wed Sep 14 05:53:39 2016

Fix the wrong candidate window on Mac OSX.

After http://crrev.com/dac0c7af14c29c9d8509b775d5044e5448b6263b,
renderer no longer capturing the composition bounds by default.
To receive the latest composition bounds from renderer, we need to
update the monitor state and it was done for aura platform in above
CL. This CL introduces the similar logic to RWHVM to fix the wrong
candidate window issue.

BUG= 639552 

Review-Url: https://codereview.chromium.org/2296623002
Cr-Commit-Position: refs/heads/master@{#417877}
(cherry picked from commit fbd66b59cd50bacb823d7aeb6396f32594583fb1)

Review URL: https://codereview.chromium.org/2337783004 .

Cr-Commit-Position: refs/branch-heads/2840@{#358}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/3c0e829d4ed12936c68a34ec918acaf4d9f7c0ef/content/browser/renderer_host/render_widget_host_view_mac.mm

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

commit 3c0e829d4ed12936c68a34ec918acaf4d9f7c0ef
Author: Seigo Nonaka <nona@google.com>
Date: Wed Sep 14 05:53:39 2016

Fix the wrong candidate window on Mac OSX.

After http://crrev.com/dac0c7af14c29c9d8509b775d5044e5448b6263b,
renderer no longer capturing the composition bounds by default.
To receive the latest composition bounds from renderer, we need to
update the monitor state and it was done for aura platform in above
CL. This CL introduces the similar logic to RWHVM to fix the wrong
candidate window issue.

BUG= 639552 

Review-Url: https://codereview.chromium.org/2296623002
Cr-Commit-Position: refs/heads/master@{#417877}
(cherry picked from commit fbd66b59cd50bacb823d7aeb6396f32594583fb1)

Review URL: https://codereview.chromium.org/2337783004 .

Cr-Commit-Position: refs/branch-heads/2840@{#358}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/3c0e829d4ed12936c68a34ec918acaf4d9f7c0ef/content/browser/renderer_host/render_widget_host_view_mac.mm