Unable to reproduce the issue on chrome reported version# 71.0.3559.6 using Windows-10 with steps mentioned below:
1) Launched chrome reported version and added Japanese IME
2) Entered text in omni box and pressed Enter, only text got entered in the omni box and again clicked on enter, then it shows result for entered text.

Observations: Also tested the issue on YouTube page, Entered YouTube.com in omni box and pressed Tab, Tab-to-search is initialized, entered some text in the omni box and pressed enter, text got entered and again pressed enter, then it shows search results in YouTube page.

@Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in further triaging it.

Thanks!

Deleted: 890203.mp4 2.0 MB

	890203.mp4 2.0 MB View Download

Your screencast already demonstrated the issue. But as you appeared to have misunderstood what I meant by input is "entered (confirmed)", let us be exact:

1. Invoke a tab-to-search (the feature you triggered at 14~15 second in your video).
2. Switch to Japanese IME.
3. Type su shi, you expect to get すし.
4. Instead you will get ｓうし. (the first s immediately gets confirmed without suspending to be combined with u to form す)

Thank you for providing more feedback. Adding the requester to the cc list.

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

Able to reproduce the issue on reported chrome version 71.0.3559.6 and on latest chrome# 71.0.3568.0 using Windows-10, hence providing Bisect Info
Note: Issue is specific to Windows

Bisect Info:
================
Good build: 71.0.3544.0
Bad build: 71.0.3545.0

Note: On running per revision bisect got error messages, hence performed chromium bisect for above mentioned range
You are probably looking for a change made after 589097 (known good), but no later than 589098 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/cc704901b1876e8cab502bac46b955d78ea0198a..c9aa3e02228a245731ee592179b07944c4585f61
Change-Id: I8d81a8fa6a6528bb12c5e0ba3faff716610410b6
Reviewed-on: https://chromium-review.googlesource.com/1185300

@Kevin Bailey: Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Beta for M-71, feel free to remove it if not applicable.

Thanks!

Unfortunately, tab-to-search may mean a couple things recently. My CL refers to tab switching - a new feature - while the bug apparently refers to keyword search, which may be triggered with tab, space or clicking.

I'm not sure my CL affects keyword mode, however, you seem to have bisected it to this accessibility CL, so I'll start looking there.

Some update: If someone would like to duplicate this, you should (for desktop such as Linux) install the Google Input tools extension, click on the new icon to set it up, add English (assuming you prefer) and Japanese (the one with US in the name worked for me). Then, with English selected, enter some searchable site in the Omnibox, first switch to Japanese, then hit tab, then type "su".

Note that it only occurs the first time you enter keyword mode. If you backspace and hit tab again, it won't happen.

The good and bad news is that, while I can duplicate it on dev channel ChromeOS and Linux, I can't on top-of-tree. So maybe it's fixed, or maybe just doesn't show up in a debug build or some other difference. I'm still looking.

As noted in the original report, this sounds a bit like  bug 883952 , which is another omnibox bug that involves an IME and also causes searching right away when pressing enter.  However, that bug is on a different platform and has different repro steps.

Meanwhile, there's  bug 890190 , which involves pressing enter in an IME and the first time the omnibox doesn't navigate (when it should).  Comment number 3 there has some useful background on how enter is handled, which may point to the bug in Views.

In my repro steps (and I believe the OP's) you don't have to hit enter. Just typing "su" will leave the "s" behind.

I'm beginning to think that my CL has nothing to do with it, simply based on where the changes are and what they do. Although perhaps it changes timing?

I too would be surprised if your change has something to do with it.  Maybe you can try to bisect yourself and see if you get the same result?

Using the good build and bad build version numbers from comment #5, I see the following blamelist:
https://chromium.googlesource.com/chromium/src/+log/71.0.3544.0..71.0.3545.0?pretty=fuller&n=10000
I don't see anything else that looks likely either.

Looking closer at your change, I see one worrying thing.  In omnibox_popup_model.cc
https://chromium-review.googlesource.com/c/chromium/src/+/1185300/9/components/omnibox/browser/omnibox_popup_model.cc
I see a new call to OnTemporaryTextMaybeChanged().  I know from experience that this function has lots of weird (and unexpected to me) side effects.  If your change is the culprit (I wouldn't place money it), I think that's the cause (I'd place money on that :-)).

> Note that it only occurs the first time you enter keyword mode. If you backspace and hit tab again, it won't happen.

This is not true for me (Windows) though. I explicit tested this and have confirmed that it always reproes as keyword mode is invoked, via Tab, Space, or clicking alike.
And the timing of IME switching is irrelevant. Switching then enter keyword mode, or enter keyword mode then switching, both will do, even when the switching is done via hotkey combinations.
Perhaps I have Windows 7 and thus some old versions of IMEs, or this bug just manifests worse on Windows.

Also Dev channel has just been updated to 71.0.3559.6 and I can still repro, if it is not far behind the then-ToT when you tested.

@mpearson, ya, I Was worried about that code too (on check-in) but it's not even called when this occurs. I believe it's called if you navigate around the suggestions?

My next suspicion were the changes in autocomplete_match_type, but those are no-ops if the tab switch button isn't focused.

Regarding the blame list, that is a much bigger list than I thought. I thought it was only my change originally. I really have no suspicions about my change any more.

Regarding bisecting, ya, as I mentioned in #c8, I can't duplicate it in a private build. (And now I can't duplicate it in 71.0.3559.6. Oddly, Google Input Tools updated right before the problem disappeared.)

Regarding "first time", it may not happen for you, but it happens for me, which has implications. I initially thought that this might be some sort of "bad initialization on entering keyword mode", but the other thing I do to duplicate this is flip keyboards. Thus, the IME is at least on the suspect　list. (I would try switching keyboards outside of keyword mode, but I can't duplicate it anywhere anymore.)

Finally, given that large change list, we might also look for changes in the IME API.

Only now I realized I have copied the wrong version number in #12. I meant 71.0.3569.0.

Friendly ping to get an update as it is marked as beta blocker.
Thanks..!

I've now tried on Windows, and asked a co-worker to try (on Windows). We can't duplicate it past the extension version of 9.0.0.1. I will call it 'closed, cant duplicate any more', but if you find a way to duplicate with these versions, let us know.

Pardon? This is never an extension issue to begin with. It is about using Windows'... presumably Microsoft's CJK IME on Windows Chrome.
(yea I didn't emphasize that, but it's not like average users would do the extra work installing Google Input when native IMEs are readily available, granted GI is better)
As your TE team has successfully reproduced it on and specified this is Windows only.

I was baffled when you started your investigation with Google Input 'extension' (and not on Windows) and never imagined a conclusion being made based solely on it. They are not the identical animal with OS-wide IMEs, are they?

Additionally verified reproducible on a Windows 10 machine with freshly installed latest canary 71.0.3576.0 using OS built-in Japanese IME and traditional Chinese new phonetic IME.

I'll summarize my steps up to now. I think the conclusion will be clearer.

I attempted to duplicate the bug on both Linux and ChromeOS, because that's what I have easiest access to, the easiest method of debugging and btw, all these platforms use the same code, if the problem is in this area. I used GIT because it's easiest to enable on those platforms. I was able to duplicate the issue on both platforms. I concluded: not Windows only, and not Windows IME only.

Later, while attempting some internal bi-section, I noticed that the extension updated itself, and that the problem went away. Maybe something got fixed, maybe there was a bug in the IME.

Not content to let it go, I then tried on Windows. I couldn't duplicate it (with GIT. A co-worker couldn't either.)

You mentioned that you can still duplicate it with the Windows OS IME. I just tried it with the Windows OS IME and couldn't duplicate it. This was with half width Katakana on Chrome 71.0.3573.0.

Maybe there's some harder to duplicate interaction between the IME and Chrome, but we're not getting any closer to the Omnibox's keyword mode. I'm cc'ing someone who may have recently done some work with the IME API. Perhaps he has a theory.

The "Tab-to-search" window you describe is a feature of Microsoft's input method -- not Chrome. It's actually just offering a completion in the candidate window like it would a Kanji phrase.

I enabled Microsoft's Hiragana input on Windows 10 and I couldn't reproduce this. It might be a Windows 7 bug that Microsoft have fixed. (I tried to take a screencast but my Windows machine died :/).

Deleted: Screenshot from 2018-10-11 17-09-53.png 42.9 KB

	Screenshot from 2018-10-11 17-09-53.png 42.9 KB View Download

I am demonstrating the issue once and for all to annihilate further misunderstanding.

In video is another Windows 10 machine. I also ask a favor of a friend installing canary to try a repro and he succeeded as well. Counts TE team's repro in that's total five independent machines. The issue exists and is existing.

I have been around here since Chrome's young days, had good times and bad times with developers, knowing the 'it works on my machine' curse well, yet rarely seen it unilaterally became the testimony of a WontFix.
I believe it is the mission here to ensure an issue－a real bug that is, save those working-as-intended things－is no more reproducible at least than one machine, and on principle, ensure it is not reproducible anymore.
Focus on it or not, cc'ing more brains or not (not really, we certainly need more help here), I would suggest leaving this bug open, removing release blocker if it bothers, but not conveniently close it to create the false assumption to the team that there is no bug, not when five diverse machines can reproduce it with little effort.

A complete comprehensive breakdown of all actions I took in the screencast:
00:00　In a freshly installed canary, confirm the system information.
00:03　Type bing.com in omnibox, one of the default search engines that has a preset keyword.
00:07　Click the Tab-to-search icon located at the rightmost of omnibox to enter keyword mode.
00:10　Switch to Microsoft Japanese IME, it defaults to hiragana mode. (Doesn't matter though as long as it is not in alphabet mode)
00:16　Type sushi in keyword mode omnibox, expect to get すし(su+shi), getting ｓうし(s+u+shi) instead.
00:20　Backspace until keyword mode is cancelled, click the Tab-to-search icon to enter keyword mode again.
00:24　Repeat 00:16 and get the same result.
00:27　Backspace to clear the string but not cancelling keyword mode.
00:29　Type sushi and correctly get すし.

Surprise, this computer has OS-wide version of Google Japanese IME installed, let's also give it a confrontation:
00:33　Backspace until keyword mode is cancelled.
00:35　Before entering keyword mode again, switch to Google Japanese IME.
00:42　Except I use Tab key to enter keyword mode this iteration, repeat 00:07~00:29 and get the same result.

Core symptom:
In CJK IME the typed alphabets (or phonetic symbols for traditional Chinese) 'suspend' to wait to be combined with subsequent alphabets/symbols to form a CJK word. They all keep being underlined until user hit Enter to confirm the combinations, only then are the string actually inputted.
With this bug, when keyword mode is initialized, the first typed alphabet/symbol gets immediately inputted as-is without waiting to be combined.

Deleted: bandicam 2018-10-12 01-51-11-547.mp4 2.0 MB

	bandicam 2018-10-12 01-51-11-547.mp4 2.0 MB View Download

So it is branch point. Once Dev channel is updated to the branching version, presuming I can still reproduce, I am going to file a duplicate new issue to try asking for a re-triaging and to verify whether this is as well still reproducible on TE's front.

@tapted: Thought I didn't need to point you out that you had completely misinterpreted the issue. Maybe you don't mind to look again at my last comment before I file a new issue...

Hey, thanks for following up here. I think a new bug would be great! Please ensure it follows our code of conduct - https://chromium.googlesource.com/chromium/src/+/master/CODE_OF_CONDUCT.md

Issue re-filed at https://crbug.com/896962.