Skip to content

Conversation

codebytere
Copy link
Member

@codebytere codebytere commented Feb 4, 2025

Description of Change

Closes #41824
Depends on #45422.
Refs #39708.

This PR mitigates an issue where the window lost its backgroundMaterial effects on maximization - turning black and losing its rounded corners. This happened in part because we made changes in an earlier PR to set transparency for correct Mica/Acrylic visuals, but didn't take into account that we'd then need to treat it in the special ways we treat transparent windows on Windows beyond that. This PR addresses those issues by expanding transparent handling to include backgroundMaterial translucency.

This PR comes at cost of losing the smooth window animation, which is something I'm hopeful i can fix as a follow up. Our stock transparent window also has this issue.

Checklist

Release Notes

Notes: Fixed an issue where windows on Windows with backgroundMaterial lost effect on maximization.

@codebytere codebytere added semver/patch backwards-compatible bug fixes target/33-x-y PR should also be added to the "33-x-y" branch. target/34-x-y PR should also be added to the "34-x-y" branch. target/35-x-y PR should also be added to the "35-x-y" branch. labels Feb 4, 2025
@electron-cation electron-cation bot added the new-pr 🌱 PR opened recently label Feb 4, 2025
@codebytere codebytere changed the base branch from main to fix-wco-not-working-sometimes February 4, 2025 10:19
@codebytere codebytere force-pushed the fix-wco-not-working-sometimes branch from 43516c4 to 4696afe Compare February 4, 2025 10:21
@mlaurencin
Copy link
Member

When testing on Windows, the window no longer turns black, but the rounded corners are still not restored

@codebytere
Copy link
Member Author

@mlaurencin try now, fixed in 54c1726

@mlaurencin
Copy link
Member

@mlaurencin try now, fixed in 54c1726

Great! Works for me now. Also I was able to build on x64 locally, so the build job for that might just need to rerun

@electron-cation electron-cation bot removed the new-pr 🌱 PR opened recently label Feb 5, 2025
Base automatically changed from fix-wco-not-working-sometimes to main February 5, 2025 11:48
@codebytere codebytere marked this pull request as ready for review February 5, 2025 11:52
@electron-cation electron-cation bot added new-pr 🌱 PR opened recently and removed new-pr 🌱 PR opened recently labels Feb 5, 2025
@jkleinsc jkleinsc merged commit 9199d5c into main Feb 7, 2025
59 checks passed
@jkleinsc jkleinsc deleted the fix-maximize-mica branch February 7, 2025 20:00
@release-clerk
Copy link

release-clerk bot commented Feb 7, 2025

Release Notes Persisted

Fixed an issue where windows on Windows with backgroundMaterial lost effect on maximization.

@trop
Copy link
Contributor

trop bot commented Feb 7, 2025

I was unable to backport this PR to "33-x-y" cleanly;
you will need to perform this backport manually.

@trop trop bot added needs-manual-bp/33-x-y and removed target/33-x-y PR should also be added to the "33-x-y" branch. labels Feb 7, 2025
@trop
Copy link
Contributor

trop bot commented Feb 7, 2025

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

@trop trop bot added in-flight/35-x-y and removed target/35-x-y PR should also be added to the "35-x-y" branch. labels Feb 7, 2025
@trop
Copy link
Contributor

trop bot commented Feb 7, 2025

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

@trop trop bot added in-flight/34-x-y and removed target/34-x-y PR should also be added to the "34-x-y" branch. labels Feb 7, 2025
@reitowo
Copy link
Member

reitowo commented Feb 8, 2025

This seems still a workaround to me because the animated resizing seems missing, and this is actually a "manual maximizing".

The resizing animation seems needs WS_THICKFRAME to be working, but this patch disable it when maximizing.

My previous observation make me wonder if Chromium's window is actually an child window of actual app window, while a typical WPF/WinUI app seems directly apply these styles on app window.

Anyway, it is a progress 👍🏻

@trop trop bot added merged/34-x-y PR was merged to the "34-x-y" branch. merged/35-x-y PR was merged to the "35-x-y" branch. and removed in-flight/34-x-y in-flight/35-x-y labels Feb 10, 2025
@eliandoran
Copy link

@codebytere , I'm testing v34.2.0 with a browser window with the following configuration:

{
  titleBarStyle: 'hidden',
  titleBarOverlay: true,
  backgroundMaterial: 'auto'
}

If I maximize the window by pressing the maximize overlay button, it works fine (apart from the lack of animation which was already mentioned).

If I maximize the window by double-clicking the draggable region of the window (-webkit-app-region: drag;) or via right click -> Maximize the issue is still reproducible. And more problematically, now the maximize button doesn't do anything when pressed.

@nikwen
Copy link
Member

nikwen commented Apr 24, 2025

@eliandoran There's issue #46753 now. If you see additional incorrect behavior besides the issue that I linked, please file a new issue.

(In general, comments on merged PRs often gets lost. Issues generally don't.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged/34-x-y PR was merged to the "34-x-y" branch. merged/35-x-y PR was merged to the "35-x-y" branch. needs-manual-bp/33-x-y semver/patch backwards-compatible bug fixes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: Maximizing a frameless window with background material (Mica) permanently breaks the window
7 participants