Full Screen at certain resolutions causes bottom bar to overflow.

[GeorgeWL]

Full Screen at certain resolutions causes bottom bar to overflow. This only affects Title Bar Style: Custom, I'm using the Default Dark+ theme, in case it's potentially caused by that.

• VSCode Version: Version: 1.40.2 (user setup) Commit f359dd6
• Electron: 6.1.5
• Chrome: 76.0.3809.146
• Node.js: 12.4.0
• V8: 7.6.303.31-electron.0
• OS: Windows_NT x64 10.0.18362

Steps to Reproduce:

1. Open VS Code in Full-Screen
2. On specific setups, the bottom action bar is partially obscured, going beyond the edge of the screen.

Does this issue occur when all extensions are disabled?: Yes

[IllusionMH]

Looks like #83456, however it's not reproducible in insiders builds after #85266 was merged and cannot reproduce in 1.40.2 (zip download)

/cc @deepak1556

[deepak1556]

Thanks @IllusionMH , yeah it sounds similar but that one is definitely fixed.

On specific setups

@GeorgeWL can you be more specific about the setup in which you see this issue ? The resolution and how the displays are arranged. Also can you attach a video demo. Thanks!

[GeorgeWL]

Thanks @IllusionMH , yeah it sounds similar but that one is definitely fixed.

On specific setups

@GeorgeWL can you be more specific about the setup in which you see this issue ? The resolution and how the displays are arranged. Also can you attach a video demo. Thanks!

Well I'm not really sure why, but if I full screen it on my bottom screen, there's no issue there.

But on either of my two top screens, it is.

Top Left (screen 2): 2560 x 1440 (100% scaling)
Top Right (screen 3): 1920 x 1200 (100% scaling)
Center Bottom (screen 1): 3840 x 2160 (250% scaling)

Ignore the blurring, that's intentional obfuscation so don't get in trouble with work security team.

[manospasj]

I have the exact same issue. It appeared today after updating to version 1.40.2 (f359dd6).

I have a two monitor setup:

• Primary monitor: 3200 x 1800 (250% scaling)
• Second monitor: 1920 x 1080 (100% scaling)

VS Code looks fine in my primary monitor, but goes beyond the screen boundaries in my second monitor. I'm happy to provide more info in order to help resolve this

[GeorgeWL]

That's something worth noting, it did only start after the latest update (1.40.2)

Before the update, I'd had no similar issues and hadn't seen this issue.

[SonOfHans]

I'm having the same issue in 1.40.2 (issue did not exist in prior version). I have a laptop hooked up to an external monitor. The laptop screen is at 3840x2160, the monitor is at 2560x1440, and scaling is set to 250%. When Code is maximized in the external monitor, all 4 edges the window hang off the edges of the screen (it's particularly noticeable on the bottom bar, but all 4 edges are definitely doing it).

[GeorgeWL]

now that you mention it @SonOfHans yeah all 4 edges of mine hang off the edge of the screen, just only by a pixel or two, except the bottom bar, which is by like 10-20 pixels.

Temp workaround for now is to turn off the much prettier custom title bar mode.

[levrik]

Just got a new Surface Book 2 at work and that was one of the first things I noticed.
Doesn't happen on the internal screen but on an external Dell one with high DPI.

[jsgoupil]

The same thing happens on the Insider 1.41. This is particularly painful when the errors are hidden. I can't see the red squares in the scrollbar.

When it's small, it's OK...

But when it's maximized, it's not OK :(

[kosmakoff]

Having this issue with 1.41.0.

I have 2 monitors setup:

1. Laptop screen, 3840x2160, 250%, VS Code looks ok
2. Connected monitor, 1920x1080, 100%, VS Code window exceeds screen margin when maximized. Screenshot attached below:

[DanJ210]

External monitors are 1920 x 1080 (Recommended) with 100% (Recommended) scaling.

[Stanzilla]

It's a bug in Electron afaik and they don't seem to care about it that much.

[davidrimshnick]

I've had it with all this negative talk about Electron. I'm switching to Proton.

…

On Fri, Jul 17, 2020 at 7:13 PM Benjamin Staneck ***@***.***> wrote: It's a bug in Electron afaik and they don't seem to care about it that much. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#85592 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBNXX6TSZWZ7ZJJXBN5M4TR4DLI3ANCNFSM4JRVEVEQ> .

[kcbleeker]

@davidrimshnick are you positive? I don't find it so attractive. Your decision seems a little bipolar

[davidrimshnick]

Does anyone have the issue tracker link for Electron for this issue?

…

On Sat, Jul 18, 2020 at 3:06 AM kcbleeker ***@***.***> wrote: @davidrimshnick <https://github.com/davidrimshnick> are you positive? I don't find it so attractive. Your decision seems a little bipolar — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#85592 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBNXXZH6YVFU3G4CBST6ILR4FCYDANCNFSM4JRVEVEQ> .

[danielgjackson]

I have this issue, and I think I have a reliable way to reproduce it, a possible explanation, and a workaround.

Background: I have one high-DPI display on a laptop, and a standard DPI monitor.

Steps to reproduce:

1. Close all instances of VS Code.
2. Ensure standard DPI display is disconnected, leaving only high-DPI display.
3. Start VS Code.
4. Connect standard DPI display and move VS code window to the display.
5. Maximize VS Code and observe that the window now extends slightly beyond the desktop area in all directions.

Observations: At step 3, right-clicking on the title bar will display a standard-sized system menu on the high-DPI display; after step 4, right-clicking on the title bar will display a larger-than normal sized system menu on the low-DPI display. As if the DPI scaling has not quite fully changed when the window moved between the monitors. The same applies the other way around: moving a working low-DPI window to the high-DPI display shows a small system menu. Another hint: in the overflowed part (on the other monitor) clicks are passed through as if it wasn't there, so this area seems clipped for click handling.

Speculation: I have a feeling that DPI scaling used by the system menu applies to other metrics, such as the window border size (for resizing), and this difference in scaling probably accounts for the window overflowing by a small amount. It looks like it's usual for Windows to maximize slightly outside the visible area (presumably for the invisible resize border? -- Update: found this article about it ), and it must apply some offset for the client area and visual clipping. Perhaps the logic for frameless windows is not quite right: maybe EnableNonClientDpiScaling() is not called; or values from GetSystemMetrics() were cached and it was not called again after the DPI change; or there is custom maximize logic that does not properly take the metric into account; or that the offsets are themselves being DPI scaled.

Workaround: The only way I know is to close all VS Code windows and re-open them while the standard DPI display is attached

Edit: It sounds very much like the sort of thing described in this (fixed) Electron issue comment: electron/electron#8728 (comment) -- perhaps the difference is that the window changes DPI.

[danielgjackson]

I now have a good workaround for the issue, see: https://github.com/danielgjackson/vscode-maximize-fix

This program simply removes the "WS_CAPTION" window style on any VS Code windows, and this fixes the issue for me.

This is clearly not the real answer, and it may just be working around the symptoms and not the cause.

Edit: I've now made a VS Code extension for it: https://marketplace.visualstudio.com/items?itemName=danielgjackson.vscode-maximize-fix

[mwhisker]

I'm having the same issue as above, the extension posted above by @danielgjackson fixed it for me. I tried switching to native and back to custom but even with dark mode set as my default the white bar remained.

Screenshots of my monitor setup for reference. Similar to another user above I'm using a Surface with a lower resolution external monitor.

[deepak1556]

This should be fixed with latest insiders https://code.visualstudio.com/insiders/ , please comment if its still an issue. Thanks!

[mlewand]

@deepak1556 gave it a quick check:

Version: 1.50.0-insider (system setup)
Commit: e13875b77c89b95f20ccb5667e14ff164c198e57
Date: 2020-09-15T05:35:57.362Z
Electron: 9.3.0
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Windows_NT x64 10.0.19041

And still no luck for me 😢 Here's a screenshot of entire screen:

Bottom bar (as well as all other edges of the window sticks outside). Added a Google Chrome window panned to the right side of screen for comparison.

[danielgjackson]

@deepak1556 I'm afraid I don't think Insiders 1.50 fixes this issue.

I don't envy you getting to the bottom of this, it looks like a story of mixed-DPI (what was connected when launched vs connected later), window styles and client areas. Hopefully some of the following details may help you.

Firstly, I made sure I was not running my "vscode-maximize-fix" extension (which works around this issue by changing the window style).

I have an internal high-DPI monitor:

• Monitor 1: 3840x2400 (300%)

I used Spy++ to measure window coordinates, but I think it's not high-dpi aware so the ones on Monitor 1 are scaled to 1/3.

Spy++ measures a Notepad window (as it is per-monitor DPI aware) as:

• Monitor 1 maximized: (-6, -6)-(1286, 776) 1292x782 (1/3 scaled coordinates)

Spy++ measures a VS Code Insiders 1.50 (all other instances closed, opened while only Monitor 1 active) as:

• Monitor 1 maximized: (0, -6)-(1280, 770) 1280x776 (1/3 scaled coordinates)

Keeping VS Code-Insiders running, connecting an external monitor as the primary monitor (to the right of Monitor 1):

• Monitor 2: 1920x1080 (100%)

Spy++ measures a Notepad window as:

• Monitor 1 maximized: (-3846, -6)-(-2554, 776) 1292x782 (1/3 scaled coordinates)
• Monitor 2 maximized: (-8, -8)-(1928, 1058) 1936x1066

...the overflowed window coordinates of Notepad are NOT visible, this seems to be a bit of a windows hack for standard window styles to push their resizing borders off the edge, even though they're not actually visible when maximized on multi-monitors; see: https://devblogs.microsoft.com/oldnewthing/20120326-00/?p=8003

Spy++ measures VS Code Insiders 1.50 (kept open since the different-DPI Monitor 2 was added)

• Monitor 1 maximized: (-3840, -6)-(-2560, 770) 1280x776 (1/3 scaled coordinates)
• Monitor 2 maximized: (-10, -18)-(1930, 1060) 1940x1078

...the maximized window overflows on Monitor 2, and the overflow is visible on the edge of Monitor 1.

Finally, restarting a fresh VS Code Insiders 1.50 while both monitors are connected (the primary is the 100% dpi), gives:

• Monitor 1 maximized: (-3837, -3)-(-2564, 766) 1273x769 (1/3 scaled coordinates)
• Monitor 2 maximized: (0, -8)-(1920, 1050) 1920x1058

...with no visible overflow on either monitor, but a white visible band of 10 pixels along the top when maximized on Monitor 1.

Something that may be a hint is that not everything is getting reset when moving between the high/low dpi monitors: I notice that the system menu (Alt+Space or right-click title bar) is not correctly rescaling when the window moves between the two monitors.

• With both connected and launching on Monitor 2 (100%) the system menu is fine, moving to Monitor 1 (300%) the system menu appears tiny (1/3rd).
• With only Monitor 1 (300%) connected the system menu is fine, attaching Monitor 2 (100%) and moving the window to it, the system menu appears huge (3x).

...is it possible that perhaps the system metrics used might also not be getting rescaled properly (or cached)?

If you find out why the system menu is not getting rescaled, I'd bet you would be closed in finding out why this issue is happening.

(I'm running 2004 build 19041.508).

[deepak1556]

Thanks for testing @mlewand

Also thanks @danielgjackson for the added details, the core of the change is in electron/electron#25052. Basically, when WM_WINDOWPOSCHANGING occurs chromium calculates the client area insets using ElectronDesktopWindowTreeHostWin::GetClientAreaInsets which is based on the monitor in which the window is present, calculated using

MonitorFromRect(&rect, MONITOR_DEFAULTTONULL);

https://source.chromium.org/chromium/chromium/src/+/master:ui/views/win/hwnd_message_handler.cc;l=2785-2800 and returns the results in screen pixels scaled to the monitors' DPI. Finally when WM_WINDOWPOSCHANGED happens chromium will update the DWM frame which in turn calls ElectronDesktopWindowTreeHostWin::GetDwmFrameInsetsInPixels to extend the dwm frame into client area, we are currently using

HMONITOR monitor = ::MonitorFromWindow(
        native_window_view_->GetAcceleratedWidget(), MONITOR_DEFAULTTONEAREST);

most likely this is not returning the correct monitor during the drag operation, which would align with your observation. I am OOF this week, will look into this after I return to work.

Also there is a round-off error that comes with WinFrameView::GetBoundsForClientView() because its calculations are in DIP which is the cause for #85655

[deepak1556]

Need some testing help again if the latest insiders https://code.visualstudio.com/insiders/ fixes the issue. Thanks!

[camilocls]

Need some testing help again if the latest insiders https://code.visualstudio.com/insiders/ fixes the issue. Thanks!

I have a laptop 4k with a secondary 1080 screen, and with Insiders version the issue is not present.

[mlewand]

Cool, works also for me in the latest insider build 🎉 Now I'm anxiously waiting for the October release 😃

[ghost]

Workaround for me was just close all VS Code windows, disconnect my dock, reconnect my dock, re-open VS Code. Looking forward to the standard release to fix this.

[asciifaceman]

Present for me as of 1.51.0 (2020-11-05)

[mlewand]

Weird, it's fixed for me. Works like a charm @ 1.51.0.

[asciifaceman]

Weird, it's fixed for me. Works like a charm @ 1.51.0.

huh :(

I'm still having to do the Win10 System (Enhanced) scaling