I'm not sure if this is an issue on Windows or ChromeOS.
I tested this on Mac and it looks fine.
This form of zerosuggest is not launched on iOS or Android.

I do not have a theme installed (or at least I'm not aware of ever installing a theme).

pkasting, can you triage?  I know I've seen you commenting on theming/coloring bugs recently.

How does normal, non-zerosuggest interaction with the dropdown look on that same machine?

The grey background thing is weird.  Is that the selected result background?  If you select something different, is the text of the first row all the same grey or something?

Pretty sure this is Linux-specific.

the theme you are using is the GTK theme. I'm sure it's specific to that setting (and probably your particular system theme).

> Is that the selected result background?  If you select something different,
> is the text of the first row all the same grey or something?
It is the selected result background.  If I arrow to another selection, everything looks correct, including the now non-selected original item (no colored background).  Furthermore, if I arrow back to the top item so it selected again, it looks right too.  By the way, the selection color when doing all this is a kind of darkish-reddish-orange.

If I use the mouse to hover over an item in the dropdown, I see the item gets selected using a lightish-reddish-orange.  I can hover and thus highlight the bottom items in the dropdown.  The top item remains with the weird gray background.  If I use the mouse to hover over the top item, I don't see the light reddish-orange highlight; it keeps the weird gray background.

> How does normal, non-zerosuggest interaction with the dropdown
> look on that same machine?
Looks fine, no issue.  For example, top item as I type is always highlighted in the dark reddish-orange.

Hovering a selected row leaves it painted as the selected row.  It won't repaint it.

It sounds to me as if there is some sort of strange bug where, only in the zerosuggest case, and only until you interact with the dropdown, the "selected row" background color is computed as grey instead of orange?  What's the text color for selected rows -- is it that grey?  Could we be wrongly using the text color as the background color this first time?

(I did test on Windows Dev, and I can't reproduce problems -- the row highlight color is correct for zerosuggest there.)

> It sounds to me as if there is some sort of strange bug where, only in the
> zerosuggest case, and only until you interact with the dropdown, the "selected
> row" background color is computed as grey instead of orange?
That sounds like an accurate description of the problem.

> What's the text color for selected rows -- is it that grey?
When I highlight a row with the mouse (to get the light reddish-orange background color), the text color remains the same as unhighlighted rows: black of queries and green for URLs.

When I use the arrow keys to explicitly change the selection, the text in the selected row (which has the dark reddish-orange highlight) is white-ish.  Maybe I'll call it gray.  In particular query text is a light gray (close to white) and URL text is a more typical gray.

> Could we be wrongly using the text color as the background color this first time?
I can believe this.  If I stare closely at the screen, I can believe that the initial (bad) background color (above the current page URL suggestion) is the same as the text color on a line with a URL suggestion (the middle gray that appears when a URL suggestion is selected).

thanks for the report and discussion. Fix is here: https://codereview.chromium.org/2578443002/

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

commit cfd026f99e1868040b970891ba75d9394c5b8efa
Author: estade <estade@chromium.org>
Date: Wed Dec 14 03:48:23 2016

Refresh appearance of omnibox results when native theme changes.

Previous to this patch, the render texts were created just once.
In some cases that was before the view was actually added to a widget
hierarchy and therefore GetNativeTheme returned the wrong thing. This
only affects GTK theme mode because on all other platforms, there's only
ever one NativeTheme. (Incognito does use a different NativeTheme as
well but this only affected suggestions which we don't provide in
incognito.)

BUG= 672226 

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

[modify] https://crrev.com/cfd026f99e1868040b970891ba75d9394c5b8efa/chrome/browser/ui/views/omnibox/omnibox_result_view.cc
[modify] https://crrev.com/cfd026f99e1868040b970891ba75d9394c5b8efa/chrome/browser/ui/views/omnibox/omnibox_result_view.h

so I think this bug has probably been around for about 21 months (when the code was added, or whenever it was turned on by default for the first time). That means it certainly affects m56, which branched recently. It also means merging this may not be a high priority, but the patch is really simple and merging it would get the fix out to users 8 weeks faster.

Your change meets the bar and is auto-approved for M56 (branch: 2924)

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

this was merged: https://codereview.chromium.org/2573383002

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Unable to reproduce the issue on Ubuntu 14.04 with chrome version #55.0.2883.75
Seen the same behavior in chrome version #56.0.2924.51
Attaching the screen-cast for your reference, could you please look into it and let us know any steps missed while reproducing the issue. 

Deleted: Issue 672226.mp4 1.2 MB

	Issue 672226.mp4 1.2 MB View Download

I'm not sure if you followed all the steps in part (1) of the repro instructions. mpearson@ might be the best one to verify this, if we feel a strong need for verification.

mpearson@ could you please confirm whether this issue is fixed in ##56.0.2924.51 ???

Verified.  Looks fine to me now on top of tree.  Sorry, it took me a while to check.

thanks for report and verification