fix: user resizable transparent windows on win32 by mayfield · Pull Request #49428 · electron/electron

mayfield · 2026-01-17T05:17:45Z

Description of Change

Frameless windows use hit-test based resize in chromium. Version 39 of electron regressed resizable windows that did not have a "frame" on win32.

Checklist

PR description included
npm test passes
I ran tests but there were 245 fails that seemed to have nothing to do with my change. I don't know if HEAD is broken or if my windows VM is not setup correctly.
PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

notes: Fixed user resizing of transparent windows on win32 platform

mayfield · 2026-01-17T05:19:20Z

Here is my test matrix to gauge user impact...

commonOptions = {
  width: 800,
  height: 600,
  maxWidth: 1000,
  minWidth: 400,
}

version - options	Sizable by user	.isResizable()	isMaximizable()	.maximize() behavior	.restore() after maximize()	notes
38.0.0 - frame:true, transparent:false, thickFrame: true	YES	true	true	YES	PASS
39.2.7 - frame:true, transparent:false, thickFrame: true	YES	true	true	YES	PASS
40 +pr - frame:true, transparent:false, thickFrame: true	YES	true	true	YES	PASS
38.0.0 - frame:true, transparent:true, thickFrame: true	NO	false	true	YES	FAIL	not transparent, has frame
39.2.7 - frame:true, transparent:true, thickFrame: true	NO	false	false	YES, ignores constraints	PASS	transparent, NO frame
40 +pr - frame:true, transparent:true, thickFrame: true	NO	false	false	YES, ignores constraints	PASS	transparent, NO frame
38.0.0 - frame:false, transparent:false, thickFrame: true	YES	true	true	YES	YES
39.2.7 - frame:false, transparent:false, thickFrame: true	YES	true	true	YES	YES
40 +pr - frame:false, transparent:false, thickFrame: true	YES	true	true	YES	YES
38.0.0 - frame:false, transparent:true, thickFrame: true	YES	true	true	YES	FAIL
39.2.7 - frame:false, transparent:true, thickFrame: true	NO	false	false	YES, ignores constraints	PASS
40 +pr - frame:false, transparent:true, thickFrame: true	YES	true	true	YES	FAIL
38.0.0 - frame:true, transparent:true, thickFrame: true, resizable: false	NO	false	false	YES, ignores constraints	PASS	affected by #48421
39.2.7 - frame:true, transparent:true, thickFrame: true, resizable: false	NO	false	false	YES, ignores constraints	PASS	unaffected by #48421
40 +pr - frame:true, transparent:true, thickFrame: true, resizable: false	NO	false	false	YES, ignores constraints	PASS	unaffected by #48421
38.0.0 - thickFrame:false	NO	false	true	YES	PASS
39.2.7 - thickFrame:false	NO	false	false	YES	PASS
40 +pr - thickFrame:false	NO	false	false	YES	PASS
38.0.0 - thickFrame:false, frame:false	YES	true	true	YES	PASS
39.2.7 - thickFrame:false, frame:false	NO	false	false	YES	PASS
40 +pr - thickFrame:false, frame:false	NO	true	true	YES	PASS
38.0.0 - thickFrame:false, frame:false, transparent:true	YES	true	true	YES	FAIL
39.2.7 - thickFrame:false, frame:false, transparent:true	NO	false	false	YES, ignores constraints	PASS
40 +pr - thickFrame:false, frame:false, transparent:true	YES	true	true	YES	FAIL

mayfield · 2026-01-19T21:48:00Z

Hi @zoy-l, Here is the PR for the win32 resize regression. I kept the changes as minimal as possible and attempted to keep behavior identical to docs/pre-39.

zoy-l · 2026-01-20T02:23:31Z

@mayfield Hey, I'm not an API reviewer, so I can't really give any suggestions. Please be patient — someone will review it.
😃

This commit addresses the transparent window rendering issues on Windows: 1. Apply PR electron#49428 fix for CanResize() and IsResizable() - Frameless windows use hit-test based resize, not WS_THICKFRAME - CanResize() now returns resizable_ for frameless windows - IsResizable() simplified to delegate to CanResize() 2. Add SetIsTranslucent(false) for transparent windows after widget init - During widget creation, transparent windows get is_translucent_=true - This causes Win11 background material patch to call DefWindowProc(-1) - On some hardware, this causes black/grey backgrounds on focus events - Explicitly setting is_translucent_=false prevents this issue 3. Keep SetBackgroundMaterial() early return for transparent windows - Background materials (Mica/Acrylic) are not appropriate for transparent windows Fixes: electron#48554 See: electron#49428 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

mayfield · 2026-01-26T20:45:22Z

@nikwen I'm in fear that this is bit rotting. Can you provide any guidance or direct me towards avenues for raising the prio, i.e. sponsorship, proposals, better PR conformance? I apologize if I'm still not being patient enough, I do value your time.

nikwen · 2026-01-26T21:29:33Z

Sorry, we currently have a long backlog of PRs. I'm not the right person to review this. I hope someone will get to it soon.

codebytere

@mayfield can you please verify your commit?

codebytere · 2026-01-27T10:40:33Z

shell/browser/native_window_views.cc

-#if BUILDFLAG(IS_WIN)
-  if (has_frame())
-    return ::GetWindowLong(GetAcceleratedWidget(), GWL_STYLE) & WS_THICKFRAME;
-#endif


This code has been around for ~9 years and your PR doesn't describe how this fixes it or why it regressed - why was this removed?

There is a more in-depth discussion here #48554 (comment)

The PR's assertion is that window resizing for win32 is not a special-case because chromium facilitates resizing internally with its own hit-test method (outlined in above comment(s)). This hit-test method is, however, tied to CanResize, as it defers to the shell as the authority on what's permitted. This PR seeks to consolidate the behavior and expectations of IsResizable (and CanResize) to be more consistent, and remove the incorrect assumption that resizing on win32 requires the WS_THICKFRAME flag (in the most minimal way possible as a first time electron committer).

I should note, based on the comments in much of the electron shell/browser/native_window_view.cc code, I believe there is some confusion about what WS_THICKFRAME means. It's also an alias for WS_SIZEBOX and despite being very poorly documented by microsoft, more or less just means the window can be sized using an external OS border (https://learn.microsoft.com/en-us/windows/win32/winmsg/window-styles). It doesn't mean the window is not allowed to size itself, as chromium indeed can and does do.

codebytere · 2026-01-28T14:40:38Z

@mayfield this test failure looks related:

not ok 1 BrowserWindow module window states resizable state do not change window transparent without frame bounds when maximized
  resizable: expected true to be false
  AssertionError: resizable: expected true to be false
      at Context.<anonymous> (electron\spec\api-browser-window-spec.ts:5476:44)
      at processImmediate (node:internal/timers:504:21)

mayfield · 2026-01-28T21:13:34Z

re: test failure

Looks like this test was changed as part of the original regression, 3a53c71

I think the remediation is to change this back to to.be.true('resizable').

If you agree, I can add a commit to this effect or if you prefer single commits, I can replace the current one.

Let me know what you think/prefer @codebytere.

mayfield · 2026-02-09T20:54:21Z

Hi @codebytere Let me know how I can help or what I should do next.

jkleinsc · 2026-02-26T20:32:01Z

@mayfield can you rebase your PR with the latest from main?

test: revert win32 frameless and transparent resizable expectations

mayfield · 2026-02-26T22:37:23Z

@jkleinsc Should be rebased and combined into a single commit now

Ref: d98a6e4

mayfield · 2026-03-14T05:06:39Z

Hi again, in a couple days we celebrate the 2 month anniversary of this PR! :) Please let me know what I can do to help push this forward; I am at your disposal.

welcome · 2026-03-16T19:31:10Z

Congrats on merging your first pull request! 🎉🎉🎉

release-clerk · 2026-03-16T19:31:11Z

Release Notes Persisted

Fixed user resizing of transparent windows on win32 platform

trop · 2026-03-16T19:31:47Z

I have automatically backported this PR to "41-x-y", please check out #50298

trop · 2026-03-16T19:31:56Z

I have automatically backported this PR to "42-x-y", please check out #50299

trop · 2026-03-16T19:31:59Z

I have automatically backported this PR to "39-x-y", please check out #50300

trop · 2026-03-16T19:32:02Z

I have automatically backported this PR to "40-x-y", please check out #50301

electron-cation bot added the new-pr 🌱 PR opened recently label Jan 17, 2026

electron-cation bot removed the new-pr 🌱 PR opened recently label Jan 24, 2026

codebytere reviewed Jan 27, 2026

View reviewed changes

mayfield force-pushed the win32-transparent-resize-fix branch from 8209374 to 7f83b3b Compare January 27, 2026 19:28

mayfield changed the title ~~Fix for user resizable transparent windows on win32~~ fix: user resizable transparent windows on win32 Jan 27, 2026

mayfield force-pushed the win32-transparent-resize-fix branch from 7f83b3b to 1cff204 Compare January 30, 2026 01:03

jkleinsc approved these changes Feb 20, 2026

View reviewed changes

mayfield force-pushed the win32-transparent-resize-fix branch from 1cff204 to 45deeab Compare February 26, 2026 22:22

fix: user resizable transparent windows on win32

d98a6e4

test: revert win32 frameless and transparent resizable expectations

mayfield force-pushed the win32-transparent-resize-fix branch from 45deeab to d98a6e4 Compare February 26, 2026 22:31

jkleinsc added target/39-x-y PR should also be added to the "39-x-y" branch. target/40-x-y PR should also be added to the "40-x-y" branch. target/41-x-y PR should also be added to the "41-x-y" branch. labels Feb 27, 2026

github-actions bot added the target/42-x-y PR should also be added to the "42-x-y" branch. label Mar 13, 2026

jkleinsc added the semver/patch backwards-compatible bug fixes label Mar 16, 2026

jkleinsc merged commit eec3fe9 into electron:main Mar 16, 2026
76 checks passed

This was referenced Mar 16, 2026

fix: user resizable transparent windows on win32 #50298

Merged

fix: user resizable transparent windows on win32 #50299

Merged

fix: user resizable transparent windows on win32 #50300

Merged

fix: user resizable transparent windows on win32 #50301

Merged

trop bot added the in-flight/41-x-y label Mar 16, 2026

trop bot removed the target/41-x-y PR should also be added to the "41-x-y" branch. label Mar 16, 2026

trop bot added in-flight/42-x-y in-flight/39-x-y in-flight/40-x-y and removed target/42-x-y PR should also be added to the "42-x-y" branch. target/39-x-y PR should also be added to the "39-x-y" branch. target/40-x-y PR should also be added to the "40-x-y" branch. labels Mar 16, 2026

This comment was marked as off-topic.

Sign in to view

Conversation

mayfield commented Jan 17, 2026 • edited by jkleinsc Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of Change

Checklist

Release Notes

Uh oh!

mayfield commented Jan 17, 2026

Uh oh!

mayfield commented Jan 19, 2026

Uh oh!

zoy-l commented Jan 20, 2026

Uh oh!

mayfield commented Jan 26, 2026

Uh oh!

nikwen commented Jan 26, 2026

Uh oh!

codebytere left a comment

Choose a reason for hiding this comment

Uh oh!

codebytere Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

mayfield Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

codebytere commented Jan 28, 2026

Uh oh!

mayfield commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mayfield commented Feb 9, 2026

Uh oh!

jkleinsc commented Feb 26, 2026

Uh oh!

mayfield commented Feb 26, 2026

Uh oh!

mayfield commented Mar 14, 2026

Uh oh!

Uh oh!

welcome bot commented Mar 16, 2026

Uh oh!

release-clerk bot commented Mar 16, 2026

Uh oh!

trop bot commented Mar 16, 2026

Uh oh!

trop bot commented Mar 16, 2026

Uh oh!

trop bot commented Mar 16, 2026

Uh oh!

trop bot commented Mar 16, 2026

Uh oh!

This comment was marked as off-topic.

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

mayfield commented Jan 17, 2026 •

edited by jkleinsc

Loading

mayfield commented Jan 28, 2026 •

edited

Loading