It appears to only happen when ZeroSuggest is active, but not 100% sure that I haven't seen it after editing the URL.

This is probably hitting the OmniboxEditModel's RestoreState() call.
https://cs.chromium.org/chromium/src/components/omnibox/browser/omnibox_edit_model.cc?l=164

Generally when you switch tabs or switch from another application back to Chrome, Chrome tries to restore the state of the omnibox to the correct thing, i.e., put it in focus if it should be, make sure the text is how you left it, etc.

We don't store / restore the cursor position when restoring the state.  That's probably the issue.

Generally this isn't an issue because the tab (if focus should be in it) starts out entirely selected.  I think that behavior makes sense (makes it easy to clobber and start over and also not too difficult to edit).  Thus, I think the root issue is that you're not seeing the omnibox text selected and instead seeing the cursor at a particular position.

> We don't store / restore the cursor position when restoring the state.

OmniboxViewViews::SaveStateToTab() and OnTabChanged() save off and restore the selection -- selection is considered the domain of the view rather than the model.

To clarify, nothing is selected. Again, we click twice, to eliminate the selection and reveal/position the cursor at the end. When we switch away, the cursor disappears, and when we switch back, the cursor is at the beginning.

I can believe that it's not saving something. It looks like all it does when we switch away is hide the cursor. This makes sense; we just leave the cursor wherever the (Textfield?) model thinks it should be.

But what part of Zero-suggest would be moving it?

I tried bisecting but since zero-suggest rarely triggers, it wasn't feasible.

For clarity, in the eyes of the code, there is always a selection -- a blinking cursor is a selection whose start and end are at the same point.

So if the cursor moves, that means the selection changed.

Trying to bisect this but somehow I was unable to reproduce the issue on the reported version: 58.0.3029.14 on Linux Ubuntu 14.04 as per the test steps in C#0. Attached is the screen-cast of the same.

Note: Tried by unchecking the 'Use a predicition service to help complete searches.../ to load pages more quickly' as well but cursor remained on the right, before and after Alt+TAB.

krb@: Could you please review the attached screen-cast and confirm if anything being missed here.

Deleted: 701519.mp4 5.8 MB

	701519.mp4 5.8 MB View Download

Chrome/upstream did not generate zero suggestions for you. That seems to be the trigger. The alternate quote services (next to the magnifying glasses) listed in the attached image are what seem to be necessary.

Deleted: required-suggestions.png 22.9 KB

	required-suggestions.png 22.9 KB View Download

I can repro this.  It looks like the key here is that the omnibox dropdown has to be open when Chrome loses focus.  Losing focus causes the omnibox dropdown to close.  When Chrome regains focus, it restores the focus to the omnibox, which causes the dropdown to open again.  This process loses the cursor position.

In general, when the omnibox loses focus within Chrome (at least in Views, which is what I'm testing with right now), we forget the cursor position. This is fine because the only way to restore the focus to the omnibox (click in it, pressing control-l, etc.) does a select-all by default, so we'd lose the cursor position anyway.

If I had to guess what's happening here, I'd guess that we're closing the omnibox upon losing focus, thus losing the cursor position, before we save the state that we're going to restore later.

Well, this is informative: https://cs.chromium.org/chromium/src/chrome/browser/ui/views/omnibox/omnibox_view_views.cc?type=cs&l=775

Heh, in other words, we intentionally forget the cursor position in an unmodified URL when it loses focus so that when we restore it, we can update the URL if it changed while the user was editing it?

(After all, it doesn't make sense to restore the cursor position in a new URL.)

This almost sounds WAI (for security reasons).

It's complicated.

Assume the user is not typing, just arrowing around.  In this case input is not considered to be in progress.  If ZeroSuggest does not trigger, then the popup is not open.  So if the underlying page navigates and the URL changes, that change will be reflected immediately ( https://cs.chromium.org/chromium/src/components/omnibox/browser/omnibox_edit_model.cc?l=203 ), while the cursor is in the omnibox.  So, if the omnibox loses focus, we can just close the popup without going further and calling RevertAll(), precisely so we can preserve the cursor position.

But if ZeroSuggest triggers, then the popup opens.  If the popup is open while the underlying URL changes, we won't show it.  If we then lose focus and close the popup, we call RevertAll() to ensure we show the new URL immediately.  As a side effect of that call, we lose the cursor position.

There are two ways to fix.  We can save the selection, call RevertAll(), and immediately restore it.  Or we can refactor such that we can do the "update text" parts of reverting without the "reset selection" portion.

Actually, I didn't check whether a URL update, while the cursor is in the omnibox, will reset the cursor position.  If it will, then we need to decide if that makes sense.  If no, then comment 11 stands, and we fix that as well.  If yes, then modify comment 11 to say that the best fix is probably to just modify the existing conditional to check "and the permanent text does not match the visible text".

Issue 299186 has been merged into this issue.

Also see bug 299186, which is a complaint that the select-all state isn't restored when coming back to Chrome.

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

commit 83a82e0c55fca9efc29c89dd5852fdbfe6118889
Author: krb <krb@chromium.org>
Date: Wed Apr 26 23:04:37 2017

[omnibox] Narrow condition for resetting selection

Previously, we were resetting the selection if text could have been
changed. Now, only do so if we spot difference. Fixes cursor location
after an alt-tab focus change.

BUG= 701519 

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

[modify] https://crrev.com/83a82e0c55fca9efc29c89dd5852fdbfe6118889/chrome/browser/ui/views/omnibox/omnibox_view_views.cc
[modify] https://crrev.com/83a82e0c55fca9efc29c89dd5852fdbfe6118889/chrome/browser/ui/views/omnibox/omnibox_view_views.h
[modify] https://crrev.com/83a82e0c55fca9efc29c89dd5852fdbfe6118889/chrome/browser/ui/views/omnibox/omnibox_view_views_browsertest.cc
[modify] https://crrev.com/83a82e0c55fca9efc29c89dd5852fdbfe6118889/components/omnibox/browser/autocomplete_controller.h
[modify] https://crrev.com/83a82e0c55fca9efc29c89dd5852fdbfe6118889/components/omnibox/browser/omnibox_edit_model.h

Fixed?