I assume this is because the work area is too small to fit the dialog and not because we're reading display height or something else. It looks like the zoomed area is about 300-350dp tall. If we need to permit that I think we need to look more holistically on our dialogs.

Trent probably knows this better but I'd guess think we assume that bubbles have sufficient height and can always fit in the display. If we need bubbles in general to fit in smaller area like this I guess we should adapt our bubble host classes to essentially always install a scroll view or something similar so that they can at least be scrolled in.

Tangentially I also assume we might run into similar problems if we do a vertical split and our minimum toolbar width doesn't fit. I'm not sure if we support vertical split for zooming or how tight that could get.

I found this while I was working on a fix for extension dialogs (See  issue 868625 ).

Here's my CL that fixes this: https://chromium-review.googlesource.com/c/chromium/src/+/1262646

Bubbles can only "flip" if they don't fit in the work area. This bubble does do that. So it's *trying* to respect the work area, it just can't improve its position because the work area is too small.

A ScrollView was added for the profile menu as part of  Issue 869343 

That's probably the right fix here. I can't think of a better way to ensure this dialog fits in screen. There will always be pathological that don't fit, even without the magnifier. E.g. websites that have a ton of permissions, or a lot of things that are administrator-controlled (see attached).

Deleted: flipped.png 4.6 MB

	flipped.png 4.6 MB View Download

Deleted: admin_controlled.png 1.8 MB

	admin_controlled.png 1.8 MB View Download

Deleted: so_tiny.png 616 KB

	so_tiny.png 616 KB View Download

Given that nothing will actually fit into "so_tiny.png", do we need a system wide fix or do we just shrug it off?

I cheated a bit in `so_tiny.png` :). The keyboard is an overlay now - it shouldn't restrict the work area. There's also a floating on-screen-keyboard now, so I wouldn't worry too much about it.

Assigning to cthomp for further triage.