I can reproduce this on stable too. Might be an old issue? It happens with the first navigation in a new window.

Deleted: omnibox_selection_flash.mp4 4.6 MB

	omnibox_selection_flash.mp4 4.6 MB View Download

Possibly related to bug 586460, see comment #2.  Or maybe it's better said that the other bug, especially comment #2, is related to this one. :-)

Some debugging is hinting that, in 'OmniboxViewViews::Update()', 'was_select_all' is true, only because 'text()' and the model's selected text are empty. Then, on line 227, 'SelectAll()' gets called.

Maybe a simple '&& !text().empty()' would help (unless there's still a mystery why the model's selection is empty.)

krb@, on one hand, I think your assessment is right, especially given the comment near the code.  Given its detail, I think it would mention if there was a reason to mark empty text as always-select all.
https://cs.chromium.org/chromium/src/chrome/browser/ui/views/omnibox/omnibox_view_views.cc?l=207-213

On the other hand, this is a Mac bug, and I thought OmniboxViewViews was only a uh, non-Mac, desktop-platforms thing...

Oh, but it looks like Mac's IsSelectAll does the same thing that Views' does (text == selected text).

Care to check that this also appear on Windows (that would help confirm the assessed issue) and then try your simple fix?

So not only does 'IsSelectAll()' do the same thing, but 'OmniboxViewCocoa::Update()' does the same thing with it, namely 'if was_select_all, SelectAll()', hence my suspicion.

I've tried duplicating it, but it's just so hard to see, unless there's something that pauses it in the intermediate state. That is, if you don't see it with the new code, is it really fixed? My hope was that someone could try it on Mac when I got the fix in, but I can certainly try again.

I can't see it on my Mac.

Perhaps try submitting the fix and ask the original reporter to verify that the previous canary (without the fix) still reproduces and that the canary with the fix does not?

mpearson@/kbr@: Of course, I will help you to verify it as soon as the fix is landed in Canary. Please just let me know it. Thank you in advance.

I'm not sure why cr/2942013002 didn't add a comment here, but you should be able to try it now at ToT.

Hello krb@,

I checked Snapshot 480453 (your patch was landed in 480450) and unfortunately it is still flashing.

Please find attached a screencast.

Deleted: build 480453.mov 1.9 MB

build 480453.mov 1.9 MB Download

Thanks for looking, Mehmet.

krb@, your welcome.

I am noticing a strange regression in latest Canary which could be related to your patch.

When I am navigating to e.g. google, then sometimes the https:// string does not appear. Only when I focus the Omnibox the https:// appears again.

Here is a screencast. Can you please take a look? Thanks.

Deleted: Ohne Titel.mov 1.9 MB

Ohne Titel.mov 1.9 MB Download

mehmet@, that's not happening for me (implying it's a more recent change than what's in my client). My change can only affect what is selected (towards not selected), not the text that's shown.

krb: Thanks for checking. I see this on Canary (which is build #480665). But when I use  Snapshot #480664 I can not reproduce it. I'll file a new report for it and will CC some Mac folks. May be one of them is able to reproduce it. 

mehmet@, aside from the other bug you found, can you confirm this one is fixed?

mpearson@: Unfortunately not. It is still flashing in latest Canary Version 61.0.3143.0.

Here is a screencast, where is it to see while navigating to chrome://version

Deleted: screencast.mov 422 KB

screencast.mov 422 KB Download

sorry, typo: ... while navigating to chrome://help

Still repros for me: Chrome Canary 65.0.3292.0.

Only shows the flash on the first navigation in a newly created window.  It doesn't matter if the new window shows the new tab page or the new window was created by selecting a link and doing "open in new window".  (In the latter case, note that there isn't a flash as the new window is created / navigates.  If you use the omnibox to navigate from that new window, there's a flash.)

May be helpful: This doesn't happen when you click on a Bookmark item on the Bookmarks Bar for first navigation in a window. So, this seems to be a problem with the ENTER key press.

I can take another look at this in the next few days, focusing on the Mac (no pun intended.)

So some bad news. As far as the Omnibox code is concerned, it isn't doing anything different between the first and second occurrence. The difference seems to be in a call from the NS stack to setSelectedRange. I recall that Cocoa has a concept of not picking an end to a selection until the user hits a key. This seems similar, in that once it's done, I don't see the call again. I was thinking that we could force it in the first place, to avoid it later, but I'll have to get some Cocoa assistance for it, as I don't understand what we're quite triggering here.

I just tried this again and I'm sorry, but I'm not seeing any highlighting. I open Chrome, type in chrome://help (or about, or version) and hit enter. The contents of the Omnibox jump straight to chrome://settings/help. Version says 65.0.3311.0. Maybe someone who can see it can try some experiments.

I can reproduce it with Version 65.0.3319.0 on macOS 10.12.6. Maybe it depends on how powerful your device is. For example, on my low-powered MacBookAir 11 from Mid 2012 it is more noticeable than on my iMac. (Both are Non-Retina devices).

Hey krb,

Did https://codereview.chromium.org/2942013002 fix the issue? The comments seem to indicate it's still flashing.

I'd like to revert that CL, as reverting it fixes a bad interaction with Steady State Elisions and the Cut (to clipboard) action. See  bug 838159 .

This seems like a red herring. I'm not seeing how behavior with empty text would affect your scheme.

I can see that it prevents the second SelectAll(), but only if the text was empty. If there's some weird interaction, ok, but my concern is that reverting this makes us worse off; to move forward, someone would have to fix both issues.

Did this trigger a regression?

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

commit d4a645adda7ce0afe684c57da08799b34cb9f86b
Author: Tommy C. Li <tommycli@chromium.org>
Date: Tue May 08 19:20:13 2018

Omnibox: Update outdated comment in OmniboxView.

This CL updates the comment to be in line with acutal behavior as of:
https://codereview.chromium.org/2942013002

Bug: 729415
Change-Id: Iab429d507a3ff6e700d0230d9fd03c6054326df2
Reviewed-on: https://chromium-review.googlesource.com/1048176
Reviewed-by: Kevin Bailey <krb@chromium.org>
Commit-Queue: Tommy Li <tommycli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556920}
[modify] https://crrev.com/d4a645adda7ce0afe684c57da08799b34cb9f86b/components/omnibox/browser/omnibox_view.h

Able to reproduce this issue on build without fix(checked on 66.0.3359.139) using Mac 10.13.3. Hence verifying the fix on latest canary 68.0.3425.0.

Now not observing any URL highlight in omnibox. Attaching screencast for reference.

As fix is working as expected adding TE-Verified labels.

Thanks! 

Deleted: 729415_M68.mp4 633 KB

	729415_M68.mp4 633 KB View Download