Also, you can hit it with the default search engine by typing google.com and continuing from step 4.

Kevin, can you look into this?

I can duplicate it. I type "wik", arrow down to wikipedia.org so it says, "Press [Tab] to search Wikipedia (en)". I then focus away and back, then hit tab.

The problem seems to emerge in OmniboxEditModel::StartAutocomplete. user_text_ is empty, but MaybePrependKeyword returns "wikipedia.org" to input_text. GetText() contains "https://www.wikipedia.org" so GetSelectedBounds() passes 25 back to cursor_position. is_keyword_selected() is true, so cursor_position is bumped by 14 - 0, taking it way past the input_text.

I tried simply bisecting it, but the issue seems to depend on the profile. Thus, all the versions either display the same issue (or no issue) or reject the profile.

I could add a defensive check here, and cap cursor_position to input length (it seems to work) but it would be nice to track down whichever path is causing this.

[downgrading priority, as Chrome still behaves reasonably]

Where is this "https://www.wikipedia.org" coming from?  The omnibox displaying "wikipedia.org".

I kind of wonder if the problem might be in the edit model's save and restore state code.

It only displays https... if I arrow to the suggestion. If it inline completes, it stays wik... (and I confirmed that GetText() contains "wik..."
when it dchecks.)

Oh I get it.  The problem is necessarily loss of focus or anything, it's trying to enter keyword mode when what you typed is not exactly the keyword.

If that's true, I'd imagine doing the following would hit the dcheck:
1. Type www.wikipedia.org.
2. Press tab.
(I cannot check at the moment.)

Theory:
It's like StartAutocomplete() receives an user text and also looks up the cursor position.  The user text has already been corrected to remove the typed keyword.  The cursor position looked up is relative to the original text.  StartAutocomplete tries to make a correction here.  However, the correct doesn't work if the stripped typed keyword is not actually identical to the keyword appended.

More progress: It looks like the primary difference between before and after focus is the pop-up state visavis OmniboxEditModel::AcceptKeyword; it simply doesn't call StartAutocomplete() which triggers the dcheck. But I still don't understand what's different about the configurations (older builds or profiles) where this path works.

Regarding your suggestion, no, typing that in doesn't cause a dcheck (in a set-up which otherwise does trigger.) The contents of variables in AcceptKeyword() right be diving into StartAutocomplete() is:

user_text_ ''
keyword_ and view_->GetText() 'www.wikipedia.org'
is_keyword_hint_ false
cursor_position_ 17
pop-up is open (so no surprise it didn't die)

but when I went back to it, restoring focus:

keyword_ and view_->GetText() 'wikipedia.org'
cursor_position 13
pop-up is closed

If it helps, this was bisected to https://codereview.chromium.org/2435103002.

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

commit a4f22089244494dcf2f506d96233431c85b5e4d1
Author: Kevin Bailey <krb@chromium.org>
Date: Fri Jan 12 14:25:25 2018

[omnibox] Narrow condition of detecting keyword state

StartAutocomplete() is passing the wrong cursor position because
it is treating an edge case of entering keyword mode as already being
in keyword mode.

The current code bumps the cursor position on any expansion of
the text, but in fact the cursor doesn't move unless there is
extra text, so test for that.

Bug:  794407 
Change-Id: Iced2f76c4ee74ff4583f68f99f090f36d84a8c70
Reviewed-on: https://chromium-review.googlesource.com/833968
Commit-Queue: Kevin Bailey <krb@chromium.org>
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528939}
[modify] https://crrev.com/a4f22089244494dcf2f506d96233431c85b5e4d1/components/omnibox/browser/omnibox_edit_model.cc

Tested this issue on Ubuntu 14.04 using chrome latest dev #65.0.3322.0 by following steps mentioned in the original comment. After step-6 observed 'en.wikipedia.org' is displayed in the omnibox.

By checking the same issue on chrome M65 #65.0.3290.0, After step-6 observed 'en.wikipedia.org' is not auto filled instead the omnibox changes the search engine to default wikipedia page.

krb@ Could you please let us know if the above behavior is the expected to verify this issue from Chrome-TE end.

Thanks!

Deleted: 794407.png 105 KB

	794407.png 105 KB View Download

The transition to keyword mode will only occur (afaik) if you go to wikipedia.org and perform a search there. This adds the search engine to your Chrome profile. Just visiting the site doesn't add it for me.

Phrased better: "...will only occur *after* you've gone..."

Tested this on Linux 14.04 using latest ToT build # 65.0.3322.0

Steps followed:
1. Created a new chrome profile and searched for few words by navigating to en.wikipedia.org. It has been added in chrome://settings/searchEngines under Other search engines section
2. Click in the omnibox
3. Typed "e and "en.wikipedia.org" is auto-suggested
4. Clicked outside of Chrome to focus some other window
5. Clicked the titlebar of Chrome to focus the window again (not clicking on the omnibox itself). en.wikipedia.org is autofilled already.
6. Pressing Tab is changing the Omnibox in to search engine [en.wikipedia.org]

That is correct behavior, thanks.

As per comment #14 adding TE-Verified label for M65.

Thanks!