Preflight Checklist
Electron Version
41.1.1
What operating system(s) are you using?
Windows
Operating System Version
Windows 11 25H2
What arch are you using?
x64
Last Known Working Electron version
No response
Does the issue also appear in Chromium / Google Chrome?
No
Expected Behavior
An 800x600 window with frame: true should measure 800x600 including the titlebar.
Actual Behavior
The window measures 784x592, even though getBounds() and other APIs report 800x600. You can measure with the screenshot tool (assuming 100% scaling) or simply by creating a window with a frame and dragging it on top of one without.
Testcase Gist URL
https://gist.github.com/f663c54e89ca040de882ca00dabbc701
Additional Information
The shrinking happens because getBounds() and setBounds() operate directly on the invisible widget (HWND). The visible part of the window gets shrunk down by Chromium to fit resize insets (8px on each side and bottom, so width-16px, height-8px). As a result, windows end up smaller and with less usable space than they are supposed to have.
This isn't an issue in Chromium where developers do not have direct control over window dimensions, but it is in Electron. Even if you account for the space that's intentionally taken up by the titlebar/menubar when useContentSize: false, the content area ends up too small: it should be ~800x543, not 784x535.
(This is not a case of the "window frame" taking up the space, which would be understandable. These insets are only present to support resize hit targets.)
This problem was recently addressed on Linux (#49209) and can be solved the same way on Windows. #50706 addresses it for frameless windows with external resize targets.
Preflight Checklist
Electron Version
41.1.1
What operating system(s) are you using?
Windows
Operating System Version
Windows 11 25H2
What arch are you using?
x64
Last Known Working Electron version
No response
Does the issue also appear in Chromium / Google Chrome?
No
Expected Behavior
An 800x600 window with
frame: trueshould measure 800x600 including the titlebar.Actual Behavior
The window measures 784x592, even though
getBounds()and other APIs report 800x600. You can measure with the screenshot tool (assuming 100% scaling) or simply by creating a window with a frame and dragging it on top of one without.Testcase Gist URL
https://gist.github.com/f663c54e89ca040de882ca00dabbc701
Additional Information
The shrinking happens because
getBounds()andsetBounds()operate directly on the invisible widget (HWND). The visible part of the window gets shrunk down by Chromium to fit resize insets (8px on each side and bottom, so width-16px, height-8px). As a result, windows end up smaller and with less usable space than they are supposed to have.This isn't an issue in Chromium where developers do not have direct control over window dimensions, but it is in Electron. Even if you account for the space that's intentionally taken up by the titlebar/menubar when
useContentSize: false, the content area ends up too small: it should be ~800x543, not 784x535.(This is not a case of the "window frame" taking up the space, which would be understandable. These insets are only present to support resize hit targets.)
This problem was recently addressed on Linux (#49209) and can be solved the same way on Windows. #50706 addresses it for frameless windows with external resize targets.