fix: apply transparency settings to WebContentsPreferences

[VerteDinde]

Description of Change

In #30193, we refactored WebContentsPreferences to store its values directly and centralize logic for default values. As part of that refactor, the transparency setting was removed, and any transparent values were instead stored in the background_color_ property (e.g., background_color_ = SK_ColorTRANSPARENT.

We handle for cases like this explicitly for browser windows here:

electron/shell/browser/api/electron_api_browser_window.cc

Lines 40 to 50 in a2d993c

	// Copy the backgroundColor to webContents.
	v8::Local<v8::Value> value;
	bool transparent = false;
	if (options.Get(options::kBackgroundColor, &value)) {
	web_preferences.SetHidden(options::kBackgroundColor, value);
	} else if (options.Get(options::kTransparent, &transparent) && transparent) {
	// If the BrowserWindow is transparent, also propagate transparency to the
	// WebContents unless a separate backgroundColor has been set.
	web_preferences.SetHidden(options::kBackgroundColor,
	ToRGBAHex(SK_ColorTRANSPARENT));
	}

However, this transparency handling only applies to browser windows, and does not take into account events where the WebContents or WebContentsPreferences are created independently from the browser window, such as "-will-add-new-contents" events.

This PR adds a transparency check to web_contents_preferences, where any passed-in transparency values are checked and set the background_color_ to SK_ColorTRANSPARENT.

It also slightly amends a check in WebContents::CreateFromWebPreferences to only set a color to the RenderWidgetHostView if a color value exists. Because we're creating a window from web preferences, which don't recognize transparency, this can override transparent web contents with a white background on the window itself.

This PR has been tested on a series of gists to make sure no regressions were caused:
Background Color (gist)
Transparent Main Window (gist)
Transparent Child Window (gist)

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is 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: Fixes an issue where transparency was not always set correctly on webContents.

[miniak]

@VerteDinde this PR does not fix #31686.

[VerteDinde]

Milan and I took a look at this PR - I'm going to merge this to fix an open issue with child windows and "-will-add-new-contents", I think we'll have to take a slightly different code path for the webview issue. Changing the rwhv call to rwhv->SetBackgroundColor(SK_ColorTRANSPARENT) looks like it's causing a different issue

[release-clerk]

Release Notes Persisted

Fixes an issue where transparency was not always set correctly on webContents.

[trop]

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