[Bug]: Window resizes when setting resizable: false

[CliffReimers]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Electron Version

13.5.1

What operating system are you using?

Windows

Operating System Version

Windows 10 21H1

What arch are you using?

x64

Last Known Working Electron version

13.4.0

Expected Behavior

Window should keep size when calling setResizable(false).

Actual Behavior

Window (and content size) increases by 10px when calling setResizable(false).

Testcase Gist URL

https://gist.github.com/CliffReimers/cfc4784579006b79cef11c34c3a042b5

Additional Information

Probably caused by #31078.

[codebytere]

cc @CezaryKulakowski

[CezaryKulakowski]

I can confirm that #31078 causes the problem. For some reason window gets event WM_SIZE after thick frame is enabled/disabled. I'd created simple test app and I checked that it's not a standard winapi's behaviour so Electron must somehow invoke the resize. I'm trying to figure out where it happens.

[CezaryKulakowski]

This bug is not really a regression from #31078. The problem was also present before this change landed but it was not so clearly visible: we wasn't updating the Windows' cache so it was necessary to force the redraw by e.g. minimizing and restoring the window to observe the resize.

There are three issues here:

1. Problem described in this ticket, i.e. noticable window resize when setResizable(true/false) is called. I don't think this is really an issue: note that window size doesn't change, only content's size does. It happens because we disable resizing by removing flag WS_THICKFRAME from window's style. Removing this flag removes sizing box placed around the window which is 5 pixels wide and which is invisible (you can observe it by moving mouse pointer outside the wndow just a bit: although pointer is not over the window anymore you can still resize it and you won't focus window which is beneath our window when you click the mouse button). As window's bounds don't change this 5 pixels are replaced with content and it looks like window was resized. If you decide this is really an issue which needs to be fixed (rather than expected behaviour which we can document) we can change it by not changing WS_THICKFRAME at all: window resize still won't be possible as we set maximum and minimum size of the window to the current size when we disable the resize (more about this is (2)). The only problem is that mouse pointer would still change to resize arrow (i..e. <->) when mouse pointer is placed at the edge of the window but I think it can be fixed by proper handling of WM_SETCURSOR.
2. When after window resizing is disabled and we force WM_GETMINMAXINFO to be generated (e.g. by minimizing and restoring the window) it's being shrinken by 10 pixels (it's another problem than described in (1) as in this case window's size is actually changed and it can be also reproduced on builds without fix: update Windows' cache after changing window's style #31078). It happens because we first set minimum and maximum size of the window to the current size and after that we make a call to SetCanResize which removes WS_THICKFRAME from the window's style. When window is moved (or minimized and restored) WM_GETMINMAXINFO is generated and its chromium's handler bases on min/max values which we set earlier. The problem is that we set values valid for window with different style (removing WS_THICKFRAME removes sizing box placed around the window which is 5 pixels wide) and not for the current one and it results in window being shrinked. Following app illustrates the problem:

const {app, BrowserWindow} = require('electron')
const path = require('path')

function createWindow () {
  const mainWindow = new BrowserWindow({
    x: 100,
    y: 100,
    width: 800,
    height: 600
  })
  mainWindow.removeMenu();
  let resizable = true;
  setInterval(() => {
    resizable = !resizable;
    mainWindow.setResizable(resizable);
    mainWindow.minimize();
    mainWindow.restore();
    console.log(`window : ${mainWindow.getSize()}`);
    console.log(`content: ${mainWindow.getContentSize()}\n`);
  }, 1000);
}

app.whenReady().then(() => {
  createWindow()
})

Every time when resize is disabled and window is minimized and restored it's size is shrinken by 10 pixels and after few itearations only titlebar remains. This can be fixed by changing order of setting size constraints and setting window's style via call to SetCanResize. We could also don't set minimum and maximum size of the window on Windows as it seems we do it because on Linux there is no "resizable" property of a window and we have to set both the minimum and maximum size to the window size to disable the resize.

Following commit fixes the problem:
CezaryKulakowski@722adf4

3. When thickFrame is set to false in window's options thick frame will be added to the window when resizing is disabled and enabled again. There is a guard which I believe was added to avoid this:

#if defined(OS_WIN)
  if (has_frame() && thick_frame_)
    FlipWindowStyle(GetAcceleratedWidget(), resizable, WS_THICKFRAME);
#endif

but WS_THICKFRAME will be added by chromium after our call to SetCanResize. I don't know if this is a problem we want to address.

If we would like to fix all three issues I would suggest to:

1. Do not enable/disable resizing by adding/removing WS_THICKFRAME but only by setting minimum and maximum size as we do it on Linux.
2. Add handling for WM_SETCURSOR which would prevent mouse pointer from being changed when resizing is disabled and pointer is placed on the edge of the window.

Please let me know what you think about it.

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

[github-actions]

This issue has been closed due to inactivity, and will not be monitored. If this is a bug and you can reproduce this issue on a supported version of Electron please open a new issue and include instructions for reproducing the issue.

[pushkin-]

This is still a problem with Electron 21

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

[pushkin-]

repros in v23

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

[pushkin-]

bump

[electron-issue-triage]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

[pushkin-]

repros in v26