Thanks for the report - I'll take a look.

The NextAction date has arrived: 2018-08-15

I can't repro this on Mac and don't have a Windows dev machine handy. pkasting@, help? :)

I can repro on Windows.  It looks as if arrowing down is simply failing to recompute the colors of the old or new suggestion row.

I can't take time to fix and don't work on omnibox anymore anyway.  I'd have said "assign to the omnibox team since this landed in M70" but unfortunately the CL was merged to 69 (and branch 3493, whatever that is).  I don't know what refresh effects this can have, but non-refresh is pretty broken with it, and we need that to stay working in M69 as an escape hatch, so this needs to get fixed urgently.  Elly, if you can't fix quickly, rope in omnibox team folks to help?  +CC jdonnelly for awareness.

I'm not sure what might be wrong since it works on Mac :( jdonnelly@, help? ccing pbos@ and bsep@ too. Separately I'll try to scare up a Windows machine...

I can repro it, but don't have any special insight into what's wrong. If you need a spare hand I can look at it tomorrow (CET).

#6: That would be lovely. It is almost certainly related to my change in the original report, but that change fixes a big a11y regression on Mac, so I'm not that happy to revert it on M69.

I took a look at this. The reason why it's Windows-specific is because pre-Refresh, that platform changes the text styling when the row is selected. So the row needs the styling recomputed on selection change, just is done for high contrast.

I'm inclined to re-apply the styling for all non-Refresh UI to keep it simple and in case I'm mistaken that this only ever happens on Windows. If anyone disagrees, let me know. I'll send a CL in the meantime.

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

commit f4a63b5b41e30dce3bd1dd3d595f502b1b3f2fe9
Author: Justin Donnelly <jdonnelly@chromium.org>
Date: Wed Aug 15 19:27:26 2018

[omnibox] Re-apply styling on result view selection change.

Do this only in the pre-Refresh UI, where on Windows (and possibly
some other circumstances?), the text styling is dependent on the
selection state.

Bug:  869768 
Change-Id: If4ec69bb2316b0596116210f6e3aa70d1866b182
Reviewed-on: https://chromium-review.googlesource.com/1176196
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Justin Donnelly <jdonnelly@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583353}
[modify] https://crrev.com/f4a63b5b41e30dce3bd1dd3d595f502b1b3f2fe9/chrome/browser/ui/views/omnibox/omnibox_result_view.cc

I'll validate in tomorrow's Canary and then request merge to M69.

Update :
Rechecked the above issue on Windows (7,8,8.1,10) OS  with latest Canary Chrome version : 70.0.3524.0 and the issue is Fixed.Hence adding TE Verified Label.

Kindly refer the attached screen cast for reference.

Deleted: Fixed_video.mp4 464 KB

	Fixed_video.mp4 464 KB View Download

How safe is the cl listed #9 to merge to M69? Als could you pls justify the merge to M69?

The CL listed in #9 is very safe. The scope of the change is a single line, which causes some UI values to be recomputed. It's almost certain that the only possible negative outcome would be a small performance regression. Further, the effect of the change is limited to the pre-GM2/Refresh UI, which we don't plan to run anymore except as a fallback if GM2/Refresh should be deemed unlaunchable.

The severity of the effect is limited by the fact that the issue only applies to the pre-GM2/Refresh UI, which again we only plan to use as a fallback. However, if we were to have to use it, the issue is quite severe.

Approving merge to M69 branch 3497 based on comments #11 and #14. 

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

commit 802c598e210b4c8ac8e90c5f6664bf47bed56a80
Author: Justin Donnelly <jdonnelly@chromium.org>
Date: Thu Aug 16 17:58:39 2018

[omnibox] Re-apply styling on result view selection change.

Do this only in the pre-Refresh UI, where on Windows (and possibly
some other circumstances?), the text styling is dependent on the
selection state.

Bug:  869768 
Change-Id: If4ec69bb2316b0596116210f6e3aa70d1866b182
Reviewed-on: https://chromium-review.googlesource.com/1176196
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Justin Donnelly <jdonnelly@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#583353}(cherry picked from commit f4a63b5b41e30dce3bd1dd3d595f502b1b3f2fe9)
Reviewed-on: https://chromium-review.googlesource.com/1178166
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#676}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/802c598e210b4c8ac8e90c5f6664bf47bed56a80/chrome/browser/ui/views/omnibox/omnibox_result_view.cc

Update :
Rechecked the above issue on Windows (7,8,8.1,10) OS using Beta build version : 69.0.3497.57 and the issue is Fixed.Hence adding TE Verified Label.

Kindly refer the attached screen cast for reference.

Deleted: Fixed_video.mp4 347 KB

	Fixed_video.mp4 347 KB View Download