This one's broken at every scale, it seems - even 200%.

It shouldn't be broken normally... is this related to multi-monitor or pixel canvas? If not, this is a much higher priority issue.

pixel canvas shouldn't affect event handling unless i'm missing something.

+malay

It's not related to multi-monitor or pixel canvas.  Occurs on both dev and stable, and I'd guess it's a Windows-only issue.

The basic issue seems to be that the offscreen non-client area above a maximized window is 11 pixels tall at 150% scale, but we convert that to dips before laying out or doing hit testing.  As a result, the top row of pixels comes in at 7.333 aka 7 dips, so we don't draw there and we consider hit tests there to fall outside the client area.

You can see that tabs don't quite reach the top visually, nor do the caption buttons.

Deleted: 150-maximized-tabs-dont-reach-top-of-window.PNG 589 bytes

	150-maximized-tabs-dont-reach-top-of-window.PNG 589 bytes View Download

Deleted: 150-no-pixel-canvas-gap-above-x.PNG 1.2 KB

	150-no-pixel-canvas-gap-above-x.PNG 1.2 KB View Download

Bret just informed me that I need to log out and back in to get everything fully into a single-display state; when I do that, the issue is not present.

Hmm, interesting. What keeps the state persistent across restart on windows?

#6: Windows has a notion of "global device scale factor" that's set once on login and never updated. This is only for compatibility with Windows 7's hidpi mode, but Chrome still has some bugs when the "global" and "per-monitor" scale factors don't match.

Should be fixed by:
https://chromium-review.googlesource.com/c/chromium/src/+/1214747

Thanks to tbergquist@ for the pointer to the correct code for retrieving frame thickness.