#51175: fix: preserve transparency across setResizable toggles on Windows
Description of Change
Fixes #51094
After #49428 made NativeWindowViews::CanResize() return resizable_ for frameless windows (instead of resizable_ && thick_frame_), HWNDMessageHandler::SizeConstraintsChanged() started adding WS_THICKFRAME to the window style whenever CanResize() reported true. WS_THICKFRAME is incompatible with layered (translucent) windows and destroys their transparency.
SetContentSizeConstraints already guards against this by skipping OnSizeConstraintsChanged() when !thick_frame_. SetResizable did not, so toggling resizability on a transparent window (e.g. setResizable(false) then setResizable(true)) caused the Chromium path to add WS_THICKFRAME and strip transparency.
Apply the same guard in SetResizable. Min/max constraints are still enforced — Chromium reads them from the widget delegate on every WM_GETMINMAXINFO, independent of SizeConstraintsChanged().
Checklist
- I have built and tested this change
- I have filled out the PR description
- I have reviewed and verified the changes
-
npm testpasses - PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.
Release Notes
Notes: Fixed frameless transparent windows on Windows losing their transparency after setResizable(false) followed by setResizable(true).
Backports
Semver Impact
Semantic Versioning helps users understand the impact of updates:
- Major (X.y.z): Breaking changes that may require code modifications
- Minor (x.Y.z): New features that maintain backward compatibility
- Patch (x.y.Z): Bug fixes that don't change the API
- None: Changes that don't affect using facing parts of Electron