fix: vibrant view is inserted into Views API hierarchy#42263
fix: vibrant view is inserted into Views API hierarchy#42263VerteDinde merged 1 commit intoelectron:30-x-yfrom
Conversation
|
💖 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:
Things that will help get your PR across the finish line:
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. |
|
cc'ing stakeholders as mentioned in the PR template (and nobody is currently assigned to this PR), I hope this is appropriate! @codebytere as the assignee for the relevant issue |
codebytere
left a comment
There was a problem hiding this comment.
Pulled this down and tested it and it works as expected - thanks!
|
Thank you so much for taking a look! Is there anything else I need to do to help get this merged into Electron 30? At this point it looks like just the |
|
Not that this should block merging, but it would be great if we could add visual tests for vibrancy views so we can more easily catch this in the future. A few tests reference our |
|
Congrats on merging your first pull request! 🎉🎉🎉 |
|
Release Notes Persisted
|
* fix: vibrant view is inserted into Views API hierarchy (#42263) * Update shell/browser/native_window_mac.mm Co-authored-by: Charles Kerr <charles@charleskerr.com> --------- Co-authored-by: Hans Halverson <hans_halverson@alumni.brown.edu> Co-authored-by: Charles Kerr <charles@charleskerr.com>
Co-authored-by: Hans Halverson <hans_halverson@alumni.brown.edu>
Co-authored-by: Hans Halverson <hans_halverson@alumni.brown.edu>
* fix: vibrant view is inserted into Views API hierarchy (#42263) Co-authored-by: Hans Halverson <hans_halverson@alumni.brown.edu> * Update shell/browser/native_window_mac.mm Co-authored-by: Charles Kerr <charles@charleskerr.com> Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com> --------- Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com> Co-authored-by: Hans Halverson <hans_halverson@alumni.brown.edu> Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
* fix: vibrant view is inserted into Views API hierarchy (#42263) Co-authored-by: Hans Halverson <hans_halverson@alumni.brown.edu> * Update shell/browser/native_window_mac.mm Co-authored-by: Charles Kerr <charles@charleskerr.com> Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com> --------- Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com> Co-authored-by: Hans Halverson <hans_halverson@alumni.brown.edu> Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
Description of Change
Fixes #41979 in Electron 30.
Summary
In Electron 30 setting a BrowserWindow's vibrancy on macOS will often cause the entire contents of the screen to have the vibrancy effect, wiping all actual window contents. This traces back to #35658 which replaced BrowserViews with WebContentsViews that use Chromium's Views API. We can fix this by inserting the vibrant view into Chromium's Views hierarchy by wrapping the vibrant view in a NativeViewHost.
Before Electron 30
The vibrancy setting creates a native macOS NSVisualEffectView that is inserted as a direct child of the window's contentView here. Prior to the BrowserView -> WebContentsView switch, BrowserViews were backed by native macOS NSViews which were also inserted as direct children of the window's contentView here, and the order of BrowserViews and the vibrancy view was maintained using the macOS NSView ordering APIs.
Electron 30 Breakage
After BrowserView was replaced with WebContentsView, WebContentsViews are no longer ordered using the macOS view ordering APIs. Instead WebContentsViews use Chromium's Views API (i.e. AddChildViewAt, RemoveChildView, etc). The problem is that the vibrancy view is attempting to use the macOS view ordering API whereas all WebContentsViews now use Chromium's Views API.
I think that the exact bug we're seeing in Electron 30 where the vibrancy view is moved to the top and blocks all other contents is because deep inside Chromium the Views API calls macOS's sortSubviewsUsingFunction here, using a function that moves all unregistered views (aka the vibrancy view) to the very top.
This can be solved by adding the vibrancy view into the Chromium views hierarchy so that Chromium knows how to order it appropriately. We can wrap the vibrancy view in a NativeViewHost and insert it as the first child of the root ContentsView so that it is behind both the BrowserWindow's webContents and all of the WebContentsViews.
Notes
This is a PR against
30-x-ysince this fix is specific to Electron 30. In Electron 31+ there are different issues with a potentially similar solution for vibrancy (see #41979 (comment) for more details). One proposed fix would be to revert #41326 and then apply this PR which fixes the vibrancy bugs I am seeing in 31+, but for now this PR fixes the 30 branch.Let me know if there is a better way to get this fix in, since it's technically not a backport to the 30 branch so CI is currently failing.
Checklist
npm testpassesRelease Notes
Notes: Fixed BrowserWindow vibrancy on macOS