Doesn't repro on Mac either.

Setting NextAction to make sure the Bisect happens.

C #2 >
Unable to provide bisect as we dont have bisect setup available on Chrome OS to bisect the issue.

The issue seems to regressed around :
Good Build:66.0.3341.0/10382.0.0 dev 
Bad Build :66.0.3342.0./10384.0.0 dev

Thanks!

This seems most plausible:
https://chromium.googlesource.com/chromium/src/+/1f1b9c92326037c5dbf4558a82fdc2ff0f94b2f9, [refactor] - Clean up the hack to remember context menu position for <webview>

Might be relevant because it affects drop downs on ChromeOS.
https://chromium.googlesource.com/chromium/src/+/2f443737157dd2989b0c41d14b29c8032da0b127, Chrome OS: Move policy indicator in time zone settings UI

There were also a couple of patches related to clearing textures and th elike in cc.

Assigning to the ChromeOS specific patch, because the issue is ChromeOS specific and is popup specific.

The NextAction date has arrived: 2018-02-19

This CL:

https://chromium.googlesource.com/chromium/src/+/2f443737157dd2989b0c41d14b29c8032da0b127, Chrome OS: Move policy indicator in time zone settings UI

is only used in chrome://settings/dateTime and I don't see any reason for DevTools to be affected by chrome://settings.

Passing back to schenney@chromium.org .

kebalaji@, does this still occur in the latest Canary? Does it occur on all ChromeOS devices or only a subset?

I'm trying to figure out how to triage this.

C#8-->

Able to reproduce the issue on M66- 66.0.3344.0/10423.0.0 dev channel across all the devices such as Candy,Daisy,Kip,Minnie,Cyan,Reks,Gnawty,Jerry,Peppy,Paine,Quawks 

Thanks!

Do DevTols behave differently on ChromeOS. At this point I am stuck triaging it, so over to DevTools for triage.

Assigning to author of https://chromium.googlesource.com/chromium/src/+/1f1b9c92326037c5dbf4558a82fdc2ff0f94b2f9, [refactor] - Clean up the hack to remember context menu position for <webview>

The dropdown in DevTools settings is a plain old <select><option>...</option><option>...</option></select>

ekaramad, can you take a look?

My change is not related as it deals with context menus in <webview> which is separate code from popups. Specifically, the CL linked above is removing some code which is dead and would only affect the position of a context menus for non-OOPIF <webview>'s which have been deprecated.

<select> elements are created and drawn on the renderer side using WebPagePopup/RenderWidget.

On a separate note I am not sure if I quite understand the bug. Is it about the popup appearing and disappearing without user input? Maybe it is an input bug.

I am removing myself as the owner so that the bug can go through triage process again.

There are no differences between Linux and CrOS in Blink <select> popup code. This is probably an issue of painting, compositing, or scheduling. Or just a slowness due to CPU consumption by other components.

kebalaji@, is the issue still occuring? There's been a few reversions in paint code so maybe it was related to one of those.

There's nothing different in painting code between CrOS and Linux, so I'm also at a loss why this would be CrOS specific, unless it is input related. So removing paint and adding Input for any help in triaging.

Unable to reproduce the issue on 66.0.3356.0/10443.0.0 - Kip, Link.  The dropdown menu works properly without the issue. 

> Unable to reproduce the issue

In that case, closing this hot potato.