fix: apply transparency settings to WebContentsPreferences #31685
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
67ccba5 to
8a30f4b
Compare
3 tasks
codebytere
approved these changes
Nov 3, 2021
clavin
approved these changes
Nov 3, 2021
Contributor
|
@VerteDinde this PR does not fix #31686. |
Member
Author
|
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 |
|
Release Notes Persisted
|
Contributor
|
I have automatically backported this PR to "16-x-y", please check out #31700 |
t57ser
pushed a commit
to t57ser/electron
that referenced
this pull request
Jan 25, 2022
…31685) * fix: add transparency to web_contents_preferences * fix: correctly apply transparency settings to new webContents from webPreferences
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
transparencysetting was removed, and any transparent values were instead stored in thebackground_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
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::CreateFromWebPreferencesto 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
npm testpassesRelease Notes
Notes: Fixes an issue where transparency was not always set correctly on webContents.