+tommycli@/ skare@, could any of you ptal assign to appropriate dev owner?

I don't think the omnibox team has made any changes recently with respect IME integration.  This sounds more like MacViews fallout.  ellyjones@, can you please triage?

Or maybe this isn't Mac related; I see there's  bug 883952  which reports something similar that started in Windows on M-69.

Unable to reproduce the issue on mac 10.13.6 and mac 10.13.3 using chrome reported version #69.0.3497.92.
Attached a screen cast for reference.
Observed that changing from Hiragana to Kanji in the Omnibox by pressing enter did not start a search immediately.

melodychu@ - Could you please check the attached screen cast and please let us know if anything missed from our end.

Thanks...!!

Deleted: 883952.mp4 1.1 MB

	883952.mp4 1.1 MB View Download

tapted@, halp? :)

I can repro on a personal mac. Here are some data points to perhaps narrow down the version a bit. I am OOO today but have some a few things to finish and can dig in more later. 

68.0.3440.75 beta (yep, 2 milestones ago, hadn't used this machine in a while) - does not repro
69.0.3497.23 beta - didn't repro
70.0.3438.16 beta - didn't repro

70.0.3515.0 canary (also needed update) - didn't repro?
71.0.3552.2 canary - *did repro* 

only in the omnibox, not on google.com or bing.com text field

followup thought - of course some of those versions are uninteresting due to mac views, and I should have checked to see what UI I was on in the cases where it could have been views or native. But anyway I'm able to repro fairly consistently on an updated canary if more data is helpful.

Should have mentioned my actual repro steps:
-setting the IME to Hiragana in the system menu
-focusing the omnibox
-on my standard US macbook keyboard, typing the a, b, [tab] keys
-pressing enter

I'll grab a video later.
thanks!

Comment #5 linked to the wrong bug.  Here is comment #5 posted again, correctly:
Or maybe this isn't Mac related; I see there's  bug 875146  which reports something similar that started in Windows on M-69.

I have tried the steps provided in Comment#11 and see similar behavior on Chrome version 68.0.3440.106 and 69.0.3497.92. 

I am assuming that the moment we hit "tab" after "ab" we are selecting the content in omnibox and [Enter] will lead to search. Please correct me if I am wrong. 

here's a video showing 70.0.3538.16 (no repro) and 71.0.3552.2 (repros) - not sure if this is switching writing systems or not, apologies, but the IME behavior differs in any case.

Deleted: 883942_enter_searches.mov 17.8 MB

883942_enter_searches.mov 17.8 MB Download

I think this is quite bad, but I'm only now getting a chance to look into this (I'm not on a mac so much these days). We should try to get a fix into m70.

We need to trace -[BridgedContentView insertTextInternal:]

it should get to the bottom of the method, which does

      textInputClient_->InsertText(base::SysNSStringToUTF16(text));
      hasUnhandledKeyDownEvent_ = NO;

which should swallow the [enter] keypress.

It seems, for some reason the [enter] is not getting swallowed, and going to the omnibox.

> It seems, for some reason the [enter] is not getting swallowed, and going to the omnibox.

Turns out.. when AppKit does -[NSView interpretKeyEvents:] in this instance it will handle the event completely silently. Dismissing the IME, but giving no indication that anything was actually done with the event :/

All I can think to do is completely suppress accelerator handling whenever this is marked text --> https://chromium-review.googlesource.com/1239975

adding releaseblock. This is raised in gTech's trending feedback.

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

commit c16016d6055ea6bade3efec407f8bbcb39196177
Author: Trent Apted <tapted@chromium.org>
Date: Tue Sep 25 00:18:13 2018

MacViews: Suppress post-IME key handling when there is marked IME text.

When interacting with an IME on Mac, some key sequences cause the
IME window to dismiss without any change to the text or ongoing
composition state. There is no method we can intercept when
-[NSResponder interpretKeyEvents:] does this. Currently, we assume the
event was unhandled, and it gets processed as an accelerator. This
may incorrectly cause a search to trigger in the Omnibox.

To fix, suppress post-IME key handling when there is marked IME text.
That is, if there was marked text at the start of keyDown: processing,
consider the event handled by IME, regardless of what methods it
invokes on the NSTextInputClient. Currently, only do this for tab
and enter.

Bug:  883952 
Change-Id: Ief845a82502437d8b8f5fd3593cf25f87c6447ae
Reviewed-on: https://chromium-review.googlesource.com/1239975
Commit-Queue: Trent Apted <tapted@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593766}
[modify] https://crrev.com/c16016d6055ea6bade3efec407f8bbcb39196177/ui/views/cocoa/bridged_content_view.h
[modify] https://crrev.com/c16016d6055ea6bade3efec407f8bbcb39196177/ui/views/cocoa/bridged_content_view.mm
[modify] https://crrev.com/c16016d6055ea6bade3efec407f8bbcb39196177/ui/views/cocoa/bridged_native_widget_unittest.mm
[modify] https://crrev.com/c16016d6055ea6bade3efec407f8bbcb39196177/ui/views/controls/textfield/textfield_unittest.cc

I've verified this in the 71.0.3561.0 Canary and the fix is working as intended.

Requesting a merge to m70.

This bug requires manual review: M70 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Per comment 13 this regressed in 68, not 69

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

commit 12c3daeb594d36c1f727254ad7df6d23edab41df
Author: Trent Apted <tapted@chromium.org>
Date: Fri Sep 28 00:17:34 2018

[merge-m70] MacViews: Suppress post-IME key handling when there is marked IME text.

When interacting with an IME on Mac, some key sequences cause the
IME window to dismiss without any change to the text or ongoing
composition state. There is no method we can intercept when
-[NSResponder interpretKeyEvents:] does this. Currently, we assume the
event was unhandled, and it gets processed as an accelerator. This
may incorrectly cause a search to trigger in the Omnibox.

To fix, suppress post-IME key handling when there is marked IME text.
That is, if there was marked text at the start of keyDown: processing,
consider the event handled by IME, regardless of what methods it
invokes on the NSTextInputClient. Currently, only do this for tab
and enter.

TBR=tapted@chromium.org

(cherry picked from commit c16016d6055ea6bade3efec407f8bbcb39196177)

Bug:  883952 
Change-Id: Ief845a82502437d8b8f5fd3593cf25f87c6447ae
Reviewed-on: https://chromium-review.googlesource.com/1239975
Commit-Queue: Trent Apted <tapted@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#593766}
Reviewed-on: https://chromium-review.googlesource.com/1249465
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#721}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/12c3daeb594d36c1f727254ad7df6d23edab41df/ui/views/cocoa/bridged_content_view.h
[modify] https://crrev.com/12c3daeb594d36c1f727254ad7df6d23edab41df/ui/views/cocoa/bridged_content_view.mm
[modify] https://crrev.com/12c3daeb594d36c1f727254ad7df6d23edab41df/ui/views/cocoa/bridged_native_widget_unittest.mm
[modify] https://crrev.com/12c3daeb594d36c1f727254ad7df6d23edab41df/ui/views/controls/textfield/textfield_unittest.cc

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

Commit: 12c3daeb594d36c1f727254ad7df6d23edab41df
Author: tapted@chromium.org
Commiter: tapted@chromium.org
Date: 2018-09-28 00:17:34 +0000 UTC

[merge-m70] MacViews: Suppress post-IME key handling when there is marked IME text.

When interacting with an IME on Mac, some key sequences cause the
IME window to dismiss without any change to the text or ongoing
composition state. There is no method we can intercept when
-[NSResponder interpretKeyEvents:] does this. Currently, we assume the
event was unhandled, and it gets processed as an accelerator. This
may incorrectly cause a search to trigger in the Omnibox.

To fix, suppress post-IME key handling when there is marked IME text.
That is, if there was marked text at the start of keyDown: processing,
consider the event handled by IME, regardless of what methods it
invokes on the NSTextInputClient. Currently, only do this for tab
and enter.

TBR=tapted@chromium.org

(cherry picked from commit c16016d6055ea6bade3efec407f8bbcb39196177)

Bug:  883952 
Change-Id: Ief845a82502437d8b8f5fd3593cf25f87c6447ae
Reviewed-on: https://chromium-review.googlesource.com/1239975
Commit-Queue: Trent Apted <tapted@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#593766}
Reviewed-on: https://chromium-review.googlesource.com/1249465
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#721}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}

Calling this fixed.

This should appear in Chrome Beta soon, and stable in 2-3 weeks.