I can repro.  Will take a look.

So there is clearly something I'm deeply misunderstanding here.

In my repro, Windows hands us a WM_NCCALCSIZE event with a proposed rect of size 3876*2176 - also know as 3840*2160 with 8 pixels on each side.  To my understanding, this is exactly as expected at 1x scale.  The expected behavior at this point, since Chrome doesn't draw any non-client area when maximized, would be for us to return a client rect that spans exactly the width of the screen, and exactly the height of the screen plus the 8 pixels above it.

Instead, when Chrome subsequently invokes GetSystemMetricsForDpi to find the window frame size on the left, right, and bottom (SM_CXSIZEFRAME) at 96 DPI it gets, for some reason, 4 pixels.  Dutifully subtracting that from the proposed rect, Chrome asks Windows for a 3848*2172 client area.  This is of course four pixels too large on the left, bottom, and right sides, so clipping happens.

I'm confused as to why GetSystemMetricsForDpi(96, SM_CXSIZEFRAME) returns 4 instead of the 8 that Windows seems to be expecting.  What's also interesting is that GetSystemMetrics(SM_CXSIZEFRAME), the DPI-unaware API, does return 8. 
 I'm clearly missing something important.

Evidence suggests we might also need to consider SM_CXPADDEDBORDER in addition to SM_CXSIZEFRAME:

https://blogs.msdn.microsoft.com/oldnewthing/20150508-00/?p=44904

Yes! This is definitely what's happening.  I'll post a CL in a bit.

I guess that by using the new API, we are implicitly committing to using the slightly-less-new frame metrics as well.  That does make some sense - after all, there's no need to maintain backwards compat, since I'm clearly updating how this application handles frames already - though it'd be nice if that were documented somewhere!

I also can't make the taskbar appear when using "Automatically hide taskbar"

Re: comment 5. This is likely a separate bug (possibly a Windows bug). Please file a separate issue for this.

I think this is also related:

Multi-monitor setup, windows 10, maximized Chrome on one monitor. Upon entering and exiting fullscreen (F11 / Youtube fullscreen playback), the maximized window will extend a few pixels to the other monitor. Restoring / re-maximizing doesn't resolve the issue, only a complete exit and restart of Chrome.

This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

This issue is marked as a release blocker with no OS labels associated. Please add an appropriate OS label.

All release blocking issues should have OS labels associated to it, so that the issue can tracked and promptly verified, once it gets fixed.

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

Issue 874884 has been merged into this issue.

 Issue 872616  has been merged into this issue.

 Issue 875720  has been merged into this issue.

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

commit 15633635ae43e020478d15dee584d7761beb0428
Author: Taylor Bergquist <tbergquist@chromium.org>
Date: Thu Aug 23 02:34:27 2018

Include non-resize-handle border in frame insets.

https://crrev.com/c/1149273 used a new Windows API,
GetSystemMetricsForDpi, to better handle multi-monitor high DPI frame
sizing scenarios.  However this API does not perpetuate a backwards-
compatibility behavior we were relying on before, where SM_CXSIZEFRAME
would include the non-resize-handle border space, SM_CXPADDEDBORDER,
(added in Vista) in addition to the resize handle space.  As a result,
we weren't accounting for that border space when calculating client area
insets.  This CL includes that space explicitly.

Bug:  873860 
Bug: 874884
Bug:  876687 
Change-Id: I19a9bde9c684e801cefb5f98162dba64ece295af
Reviewed-on: https://chromium-review.googlesource.com/1176824
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Robert Liao <robliao@chromium.org>
Commit-Queue: Taylor Bergquist <tbergquist@chromium.org>
Cr-Commit-Position: refs/heads/master@{#585374}
[modify] https://crrev.com/15633635ae43e020478d15dee584d7761beb0428/chrome/browser/ui/views/apps/glass_app_window_frame_view_win.cc
[modify] https://crrev.com/15633635ae43e020478d15dee584d7761beb0428/chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.cc
[modify] https://crrev.com/15633635ae43e020478d15dee584d7761beb0428/ui/base/BUILD.gn
[add] https://crrev.com/15633635ae43e020478d15dee584d7761beb0428/ui/base/win/hwnd_metrics.cc
[add] https://crrev.com/15633635ae43e020478d15dee584d7761beb0428/ui/base/win/hwnd_metrics.h
[modify] https://crrev.com/15633635ae43e020478d15dee584d7761beb0428/ui/views/win/hwnd_message_handler.cc

This issue is marked as a release blocker with no OS labels associated. Please add an appropriate OS label.

All release blocking issues should have OS labels associated to it, so that the issue can tracked and promptly verified, once it gets fixed.

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