This looks similar to Issue 877625.

We, Blink>Forms>Select owner, doesn't have CrOS + external screen.  Probably we can't fix this.

Customer provided additional workaround, which works for them - 
1. From the external screen, open the link https://developers.google.com/gsuite/add-ons/guides/css and see the problem.
2. Select another tab, click in an input field of it.
3. So, returning to the problematic tab, the contents of the list drop-down is now visible

This does not seem to be a blink fonts issue, rather on the Chrome UI side.

adding Ash component as the issue sounds like it's specific to Chrome OS secondary displays.

Hi Team. Is there any update on this?

Assigning to kenrb@ for now so that this issue can gain some traction. kenrb@ if there is someone else on the team that is better equipped to work on this please reassign accordingly.

Thank you! 

Passing this to James who had noticed this independently somewhat recently. Issue 877625 is about cross-origin iframes, and while this might be tangentially related, it happens on main frames as well.

Are there any updates on this issue?

wjmaclean@,
Is there any update that can be shared with the customer?

Looking into this now ...

So I think I understand what's going on with issue 877625, but I think this issue is different. Based on my trying it out on Linux-CrOS build run with multiple windows, it seems that the ScreenInfo is different when a tab is maximized vs. when it's not ... 

While I wouldn't expect a maximized tab to be in "full screen mode", I'm not sure what other difference there would be.

+ danakj@ who has some experience with this.

I'll continue to dig into it to see where the discrepancy is coming from ... it should be possible to track it back to the OS Display settings as access from RenderWidgetHostImpl during the creation of the popup widgets.

danakj@
As wjmaclean@ commented previously, do you know who has some experience with this?


wjmaclean@
Thanks for your support.
Is there any update that can be shared with the customer?
 

On Linux/X11 at least, the problem occurs here:

https://cs.chromium.org/chromium/src/ui/base/x/x11_display_util.cc?rcl=8c64ebf6ce90f596624c5f43ef1951c3050961bb&l=169

If the 'primary' display doesn't match the x_root_window, then the intersection between the primary display geometry and the work_area_in_pixels is empty, and at line 169 we set the display's work area to be empty.

I don't know why the work area calculated at 

https://cs.chromium.org/chromium/src/ui/base/x/x11_display_util.cc?rcl=8c64ebf6ce90f596624c5f43ef1951c3050961bb&l=122

doesn't include the primary display, though it's fairly obvious that in the case of multiple monitors that the idea of representing work area with a single rect is problematic.

When the display's work_area is empty, it seems pop-up render widgets fail.

Also note that there is another effect, namely that when first starting Chrome on the primary monitor, the content area for tabs is empty, meaning you have to resize the window before it can be used.

I did experiment with not changing the Display's work area if the intersection is empty, and this seems to resolve the problem, though I don't know if this will cause problems elsewhere.

*** Important: to repro, you may need to change which monitor you have set as your primary monitor. In my case my two monitors have very different resolutions, with the primary one having the lower resolution. In any case, a user's choice of primary monitors shouldn't make the difference between drop-down menus working and not working.

Re-assigning to thomasanderson@ as I'm guessing they know more about this part of the codebase.

Adding jkim@ to CC since they were the last to touch this code.

We shouldn't use work_area for this at all, it's intended to be the part of the desktop where desktop icons should be placed. There should be no interaction with the content of chrome windows.

In the absence of external calls to Display::set_work_area(), Display defaults to making it the same as the bounds. Perhaps content/ code has come to rely on that in a way that isn't appropriate.

As per comment# 0 from the reporter issue requires Chromebook to test and confirm it, hence routing this issue to Inhouse and requesting someone help in testing the issue using Chromebook and desktop and check if it's regression or not. Hence adding TE-NeedsTriageFromHYD label to it.

Thanks!

Actually, this problem reproduces fine on Linux without a ChromeBook (see Comment #13).