Issue 707964  has been merged into this issue.

Bumping priority as we're getting more reports of this.

 Issue 702609  has been merged into this issue.

This issue occurs if the window was previously minimized and the user clicks on
the taskbar button to restore it in the previous position. In that case,
WM_NCCALCSIZE is sent before the window coordinates are restored to their
previous values, so the left-top point of the window would probably be a pair of
big negative integers like all minimized windows. And if we invoke
MonitorFromWindow() with the handle of the window, we will get a NULL or a wrong
monitor handle depending on the option passed in.

Unfortunately, BrowserDesktopWindowTreeHostWin::GetClientAreaInsets() invoked in
HWNDMessageHandler::OnNCCalcSize() does such a thing. Whenever the user try to
restore a minimized browser window, it yields wrong insets based on a wrong
monitor and give it back to the caller. On my environment, for instance, it
gives me insets as follows:

|                        | Primary Monitor   | Secondary Monitor |
| State Transition       | (150% Scale)      | (100% Scale)      |
|------------------------|-------------------|-------------------|
| Restored  -> Minimized |                11 |             7 (a) |
|------------------------|-------------------|-------------------|
| Minimized -> Restored  |                11 |          * 11 (b) |

* is a wrong inset based on the primary monitor, not the secondary one.

The absolute value of the difference between (a) and (b) is the thickness of the
black border.

Any fix in the making for this bug?

Unfortunately not at the moment. The folks who worked on this are overcommitted at the moment.

Two more examples of this.  I have two monitors, one scaled at 250% and the second at 100%

A few issues of note:
- The black around the browser
- the oversized scrollbar
- The hover-over for the tab in the first screenshot is huge
- The file browser used to choose the screenshot to upload for this bug report is essentially taking up my entire monitor

Deleted: screenshot.png 83.1 KB

	screenshot.png 83.1 KB View Download

Deleted: screenshot2.png 99 KB

	screenshot2.png 99 KB View Download

That second image, of the common file dialog being scaled incorrectly, can be easily fixed on newer versions of Windows 10. Here is what can be done on different versions:

1703:
Run the common file dialog in a Per-Monitor V2 thread context. This can be done by either using <dpiAwareness>PerMonitorV2</dpiAwareness> in the exe manifest, or more surgically using SetThreadDpiAwarenessContext right before opening the dialog. Using the manifest will cause the entire process to default to PerMonitorV2, but you can have both the <dpiAwareness> and the <dpiAware> manifest on the same exe, and the <dpiAwareness> manifest won't be read on older versions of Windows (so that you can make the process support the new features on newer versions of Windows and run in a different awareness mode on older versions).

1607:
Run the common file dialog with system awareness thread context. This will result in Windows bitmap stretching this dialog. It will be blurry when run on a display that has a DPI that is different than the "main" display's DPI, but at least it will be the correct size. This can be done with SetThreadDpiAwarenessContext before opening the dialog. 

Windows 8.1 -> Pre 1607:
The dialog cannot be scaled properly.

Pre 8.1:
Per-monitor DPI scaling did not exist, so N/A

See this URL for more info:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt843498(v=vs.85).aspx

Also, as for the issue of calculating the insets while restoring from being minimized... I don't know how this is being calculated today but if you call GetDpiForWindow(HWND) you should receive the DPI that the window had before it was previously minimized (You won't need to try to determine the monitor from the minimized position of the window using MonitorFromWindow()). This should be fine unless the monitor that the window wants to restore to has gone away while the window was minimized. 

 Issue 717936  has been merged into this issue.

 Issue 792100  has been merged into this issue.

This is also an issue with 64.0.3282.167 (Official Build) (64-bit) running on Windows 10 Version 10.0.16299 Build 16299 in the following circumstance:

1. Start with a laptop that has a built-in high-dpi display (like a MacBook Pro booting Windows).
2. Attach an external non-high-dpi monitor.
3. Under Display settings select "Make this my main display" for the external monitor.
4. Launch Chrome -- it displays on the external monitor.

In this case the Chrome window shows the black border described above and the scrollbars are the wrong thickness. See the attached screenshot.

Deleted: chrome_hidpi.PNG 52.2 KB

	chrome_hidpi.PNG 52.2 KB View Download

I have the same issue. High-dpi laptop on windows 10 and a regular 2nd monitor at work. Chrome appears with blackbars that vary in size depending on zoom level, scrollbar is ridiculously wide. Please fix, I don't think this is an uncommon setup and the issues has been around for at least year now.

The initial fix to address this before I flipped the per-monitor DPI switch is here:

https://chromium.googlesource.com/chromium/src.git/+/39ec034d1110e65d77481e1362c8f4ba6429f7fb

This would be a good place to start the investigation.

There seem to be at least three separate bugs in this issue:
1. When I open chrome on my 100% scale primary display with a non-100% other display present, I get black bars that vary in thickness based on display scale.  I cannot repro this (on dev or stable) following either marshall@'s or peterfelts@'s instructions.
2. When I minimize and restore chrome on my 100% scale primary display with a non-100% other display present, I get black bars that vary in thickness based on display scale (presumably the same as (1)).  I can repro this following sungmann.cho@'s instructions.
3. When chrome is in a restored state on a non-100% scale display, I get 1-pixel black bars.  I can repro this.

I'm fairly certain that #3 is the same root cause as  https://crbug.com/863228 , so I'll ignore that

Correction: I can repro #1 at 200%.

 Issue 870793  has been merged into this issue.

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

commit da1724ca73e328bdafe26040eb170daf526549bc
Author: Taylor Bergquist <tbergquist@chromium.org>
Date: Wed Aug 08 18:30:33 2018

Fix letterboxing (black bars) issues in multi-monitor setups.

There are two bugs fixed here:
First, restoring a minimized window causes letterboxing in some cases:
GetClientAreaInsets as calculated by BrowserDesktopWindowTreeHostWin
is scaled by the DPI for the associated HWND.  That works great except
when restoring a window from a minimized state, during which the window
is in some weird off-screen no-man's-land and is not actually on any
display.  GetSystemMetricsForHWND() defaults to the closest display in
this case, and if that guess is wrong, you can get letterboxing.

This CL passes in the correct scale factor explicitly, so OnNCCalcSize
can pass in the scale for the display that the window is being restored
to.

Second, some setups always have (less noticeable) letterboxing.  This is
simply fixed by using the GetSystemMetricsForDpi API (if it's available)
instead of scaling the results of GetSystemMetrics ourselves and getting
letterboxing if Windows did not scale the same way.

Bug:  656730 
Change-Id: I4eedce3fc3ef427e0986f086623094152940ba2b
Reviewed-on: https://chromium-review.googlesource.com/1149273
Reviewed-by: Robert Liao <robliao@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Reviewed-by: Bret Sepulveda <bsep@chromium.org>
Commit-Queue: Taylor Bergquist <tbergquist@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581636}
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/chrome/browser/apps/platform_apps/app_window_interactive_uitest.cc
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/chrome/browser/ui/views/apps/app_window_desktop_window_tree_host_win.cc
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/chrome/browser/ui/views/apps/app_window_desktop_window_tree_host_win.h
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/chrome/browser/ui/views/apps/glass_app_window_frame_view_win.cc
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/chrome/browser/ui/views/apps/glass_app_window_frame_view_win.h
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.cc
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.h
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/ui/display/win/screen_win.cc
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/ui/display/win/screen_win.h
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/ui/views/widget/desktop_aura/desktop_window_tree_host_win.cc
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/ui/views/widget/desktop_aura/desktop_window_tree_host_win.h
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/ui/views/win/hwnd_message_handler.cc
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/ui/views/win/hwnd_message_handler.h
[modify] https://crrev.com/da1724ca73e328bdafe26040eb170daf526549bc/ui/views/win/hwnd_message_handler_delegate.h

All cases of this were resolved by that CL ^