Skip to content

fix: abnormal behavior of windows background material #47386

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 17, 2025

Conversation

codebytere
Copy link
Member

Description of Change

Follow-up to #46855

Closes #47366
Closes #46753
Closes #43345
Closes #43196
Closes #46882

  • The main reason for the background material turning black is that when the window is maximized, Chromium calls GetDwmFrameInsetsInPixels to determine whether an update is needed and sets DwmExtendFrameIntoClientArea, which disrupts the background effect.
  • Chromium's translucent value is never updated after initialization, so subsequent operations like maximizing or entering fullscreen can break the background material.
  • Translucency within Chromium windows results in windows being treated as a frameless windows, causing a white title bar to appear during subsequent updates.

Checklist

Release Notes

Notes: Fixed applying background material correctly when creating windows on Windows, restored animations, and also fixed the issue where dynamically setting the background material had no effect.

@codebytere codebytere added semver/patch backwards-compatible bug fixes target/35-x-y PR should also be added to the "35-x-y" branch. target/36-x-y PR should also be added to the "36-x-y" branch. target/37-x-y PR should also be added to the "37-x-y" branch. labels Jun 5, 2025
@electron-cation electron-cation bot added the new-pr 🌱 PR opened recently label Jun 5, 2025
@codebytere codebytere force-pushed the background-material-rework branch from 7f5ef3c to 5778823 Compare June 5, 2025 18:29
@reitowo
Copy link
Member

reitowo commented Jun 6, 2025

Fantastic fix! Thanks for digging into Chromium and find out why. Wanted this feature for long time.

@codebytere codebytere requested review from clavin and mlaurencin June 6, 2025 10:03
@codebytere codebytere marked this pull request as ready for review June 6, 2025 10:03
@codebytere codebytere requested a review from a team as a code owner June 6, 2025 10:03
@electron-cation electron-cation bot removed the new-pr 🌱 PR opened recently label Jun 7, 2025
@codebytere codebytere force-pushed the background-material-rework branch from 5778823 to 89f51c4 Compare June 8, 2025 11:00
Comment on lines +69 to +76
// We avoid doing this when the window is translucent (e.g. using
// backgroundMaterial effects), because setting zero insets can interfere
// with DWM rendering of blur or acrylic, potentially causing visual
// glitches.
const std::string& bg_material = native_window_view_->background_material();
if (!bg_material.empty() && bg_material != "none") {
return false;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has it been verified that these translucent window edges don't bleed in a multi monitor setup ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@deepak1556 no, and i might need some assistance with that as I've only one monitor!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m using a multi-monitor setup and everything looks fine during development. However, to be safe, it would be best if you could verify it on your end. @codebytere

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested the latest changes and they seem to regress the edges fix, display information

      Displays:
          Resolution: 2560 x 1600 Retina
          Main Display: Yes
        PHL27E1N5600H:
          Resolution: 2560 x 1440 (QHD/WQHD - Wide Quad High Definition)
  1. Open https://gist.github.com/hopejr/aefdd05711802dddfc4d79d7729dbc33
  2. Maximize

Overlay buttons are misaligned and edges bleed into the secondary monitor

Copy link
Contributor

@zoy-l zoy-l Jun 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

background material

normal

This is what I observed on my end; there doesn't seem to be any edge overflow...😅

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not experiencing any of these issues with my multi-monitor system on Windows. @deepak1556 were you testing on macOS?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry missed this thread, I was testing with a remote setup. https://devbox.microsoft.com/ connected from macOS windows app with multiple displays.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@deepak1556 i can try to look into this but also do we think this is potentially a worthwhile edge case to accept in service of fixing the other outstanding issues, at least for a while?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah given this only affects remote case, I don't mind following-up on that separately to avoid blocking this PR.

@codebytere codebytere force-pushed the background-material-rework branch from 0e45708 to bee0a68 Compare June 11, 2025 13:09
Copy link
Member

@mlaurencin mlaurencin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, #43345 seems to still repro for me on Windows 11 23H2.

This was the method I was trying https://gist.github.com/edbf82eca6fcfb92cf9abcb7e0161831

@github-actions github-actions bot added the target/38-x-y PR should also be added to the "38-x-y" branch. label Jun 24, 2025
@codebytere codebytere force-pushed the background-material-rework branch 4 times, most recently from 0fc3fd3 to ed49934 Compare July 7, 2025 13:28
@codebytere codebytere force-pushed the background-material-rework branch 3 times, most recently from 9212e93 to 4b8244c Compare July 8, 2025 18:30
@codebytere
Copy link
Member Author

codebytere commented Jul 8, 2025

@mlaurencin just pushed a fix for #43345 - can you test again? it's working for me now.

@codebytere codebytere force-pushed the background-material-rework branch 2 times, most recently from cf95653 to 8131f3d Compare July 13, 2025 09:26
@trop
Copy link
Contributor

trop bot commented Jul 17, 2025

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

@trop trop bot added in-flight/38-x-y merged/38-x-y PR was merged to the "38-x-y" branch. and removed target/38-x-y PR should also be added to the "38-x-y" branch. in-flight/38-x-y labels Jul 17, 2025
codebytere added a commit that referenced this pull request Jul 18, 2025
* fix: abnormal behavior of windows background material

Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>

* chore: update patches

* fix: setting background material after init

---------

Co-authored-by: zoy <zoy-l@outlook.com>
Co-authored-by: patchup[bot] <73610968+patchup[bot]@users.noreply.github.com>
@nikwen nikwen mentioned this pull request Jul 21, 2025
3 tasks
@sbenmoussati
Copy link

sbenmoussati commented Jul 28, 2025

Hi @codebytere would it be possible to backport the fix in 37-x-y?

@codebytere
Copy link
Member Author

@sbenmoussati hey sure - i'm out until thursday but i'll prioritize it then :)

@sbenmoussati
Copy link

@sbenmoussati hey sure - i'm out until thursday but i'll prioritize it then :)

Hi @codebytere I know you're probably busy — just wanted to gently check if there's any chance the fix could be backported in 37-x-y?

@trop
Copy link
Contributor

trop bot commented Aug 4, 2025

@codebytere has manually backported this PR to "37-x-y", please check out #47956

@trop
Copy link
Contributor

trop bot commented Aug 4, 2025

@codebytere has manually backported this PR to "36-x-y", please check out #47957

@trop trop bot added merged/37-x-y PR was merged to the "37-x-y" branch. merged/36-x-y PR was merged to the "36-x-y" branch. and removed in-flight/37-x-y in-flight/36-x-y labels Aug 4, 2025
jwbonner added a commit to Mechanical-Advantage/AdvantageScope that referenced this pull request Aug 10, 2025
The underlying Electron issue causing glitchy behavior was fixed: electron/electron#47386
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged/36-x-y PR was merged to the "36-x-y" branch. merged/37-x-y PR was merged to the "37-x-y" branch. merged/38-x-y PR was merged to the "38-x-y" branch. semver/patch backwards-compatible bug fixes
Projects
None yet
6 participants