fix: use default NSVisualEffectState enum case

[codebytere]

Description of Change

Closes #16417.

In Apple documentation NSVisualEffectState is an enum with three options detailing how the material appearance should reflect window activity state. We were previously using NSVisualEffectStateActive, meaning that the backdrop would always appear active. This breaks from the default as specified in the first link, which is NSVisualEffectStateFollowsWindowActiveState and means that the backdrop should automatically appear active when the window is active, and inactive when it is not. This thus changes our effect state to the more expected default.

cc @miniak @zcbenz @jkleinsc

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• PR title follows semantic commit guidelines
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.
• This is NOT A BREAKING CHANGE. Breaking changes may not be merged to master until 11-x-y is branched.

Release Notes

Notes: Fixed an issue where macOS window vibrancy active state did not always match the active state of the window.

[MarshallOfSound]

Notes: Fixed an issue where the effect state on macOS was not using the appropriate default for NSVisualEffectState.

I had to do some googling to figure this out, can we phrase this better in a way Electron devs would understand what changed. i.e. does this only impacts folks using vibrancy?

[codebytere]

@MarshallOfSound yes - it's invoked in SetVibrancy. Honestly not sure how to distill this down any better, since it is a detail that's somewhat specific to macOS-specific APIs.

[MarshallOfSound]

I assume this is a visual change, what will users see differently now?

[codebytere]

@MarshallOfSound essentially - the vibrancy active state did not match that of the window. The default behavior of native macOS apps with vibrancy is to disable the vibrancy when the window is inactive, which makes it easier for the user to see the active app. Before this fix we forced it to be active all the time, which was visually confusing.

Updated the notes to:

Fixed an issue where macOS window vibrancy active state did not always match the active state of the window.

which i think should provide more clarity.

[release-clerk]

Release Notes Persisted

Fixed an issue where macOS window vibrancy active state did not always match the active state of the window.

[trop]

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

[trop]

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

[trop]

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

[trop]

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

[greenimpala]

I understand the reasoning behind this change but can we not provide the facility to force vibrancy regardless of window state? I would like to keep the vibrancy when the window is not active.

[codebytere]

@greenimpala seems like a reasonable BrowserWindow option - happy to try and add it.

[codebytere]

@greenimpala popped up a fast PR, linked above

[greenimpala]

@codebytere Great work, looks good :)