feat: add transparent webpreference to webview

[BrandonXLF]

Add a transparent webpreference that when disabled makes webviews have an opaque background that follows the guest page's color scheme.

Fixes #40207

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation, tutorials, templates and examples are changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Added a transparent webpreference to webviews

[welcome]

💖 Thanks for opening this pull request! 💖

We use semantic commit messages to streamline the release process. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix.

Examples of commit messages with semantic prefixes:

• fix: don't overwrite prevent_default if default wasn't prevented
• feat: add app.isPackaged() method
• docs: app.isDefaultProtocolClient is now available on Linux

Things that will help get your PR across the finish line:

• Follow the JavaScript, C++, and Python coding style.
• Run npm run lint locally to catch formatting errors earlier.
• Document any user-facing changes you've made following the documentation styleguide.
• Include tests when adding/changing behavior.
• Include screenshots and animated GIFs whenever possible.

We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

[samuelmaddock]

I hadn't realized defaulting transparent to true wouldn't be compatible with the design of the HTML attribute.

transparent may still better align with existing APIs such as BrowserWindow's transparent option. I'll run this by @electron/wg-api and get back to you on next steps regarding the breaking change.

[BrandonXLF]

I hadn't realized defaulting transparent to true wouldn't be compatible with the design of the HTML attribute.

transparent may still better align with existing APIs such as BrowserWindow's transparent option. I'll run this by @electron/wg-api and get back to you on next steps regarding the breaking change.

Sounds good! I initially thought having to enable transparency seemed more intuitive since iframes are opaque by default, but I'm not sure if that warrants breaking the current default behaviour. Thanks for looking into this for me and I look forward to hearing back.

[samuelmaddock]

@BrandonXLF the @electron/wg-api discussed the API and thought of adding transparent in webview's webpreferences attribute.

<!-- Disable transparency -->
<webview webpreferences="transparent=no"></webview>

<!-- Enable transparency -->
<webview webpreferences="transparent=yes"></webview>
<webview></webview>

This would avoid the naming awkwardness and any breaking changes.

[samuelmaddock]

API LGTM

[samuelmaddock]

A few suggestions here:

• Use a list similar to the linked docs for web preferences.
• Link to native theme source. It seems like that's what's being referred to when you mentioned color scheme.

Suggested change

	The full list of supported preference strings can be found in [BrowserWindow](browser-window.md#new-browserwindowoptions)
	in addition to `transparent`.
	The full list of supported preference strings can be found in [BrowserWindow](browser-window.md#new-browserwindowoptions). In addition, webview supports the following preferences:
	- `transparent` boolean (optional) - Whether to enable background transparency in the guest page. Default is `true`. **Note:** Text and background colors are derived based on the [native theme source](native-theme.md#nativethemethemesource) by default. When transparency is enabled, the text color may still change accordingly.

[BrandonXLF]

Switched to the suggested list format and added a link to https://developer.mozilla.org/en-US/docs/Web/CSS/color-scheme.

[zcbenz]

API LGTM

[BrandonXLF]

@zcbenz @samuelmaddock It looks like one of the Mac OS tests timed out, would you be able to rerun them?

[zcbenz]

@BrandonXLF Sorry for the delay, #35658 has been merged recently and this PR has a minor conflict with it, can you rebase this branch on latest main? After that I'll merge this PR.

[BrandonXLF]

@zcbenz Done. It also looks like #35658 made webviews non-transparent by default, I've gone ahead and reverted this behaviour.

[zcbenz]

/cc @nornagon on the behavior of webview getting changed in #35658, how do you think if we merge this PR which reverts the changed behavior, and then fix the backports of 35658?

[zcbenz]

I'm merging this PR since it has implemented the API requested by API working group.

[release-clerk]

Release Notes Persisted

Added a transparent webpreference to webviews