fix: persist BrowserView content bounds when calculating layout

[andreasdj]

Description of Change

Closes: #31513

This PR reverts the change introduced in PR: #30510, to persist the content bounds of a BrowserView when it goes outside it's parent window. For background reference to see why this change was done, see: #29778.

The reason for this PR and why we think it's a reasonable change to do is the following:

• We want to have an option to shift a BrowserView to go outside of it's parent window without having the framework limiting it's bounds, which we had before.
• If the color issue can be solved by making sure a BrowserView is inside it's parent window, we would prefer to let the application developer solve this and still allow to have a choice to move a BrowserView outside of it's parent bounds.
• The color issue isn't solved with the introduced change (see: [Bug]: Setting the BackgroundColor to the BrowserView doesn't work on Windows #30700).

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed an issue where BrowserView layout bounds where limited to it's visible bounds.

[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.

[andreasdj]

Hi @nornagon, @codebytere! We understand that you are busy, and we really appreciate the hard work you put into this framework. Can we help you out in any way to get this PR moving?

We are currently stuck with electron version 13.2.1 and we really want to be able to upgrade to the latest version but this is blocking us.

The other option of doing what's been done in this PR, would be to introduce a setting for controlling the behavior when a BrowserView extends outside of a parent BrowserWindow. We don't want to spend time on that without getting some kind of feedback from you in regards to the issue though.

All the best! :)

[nornagon]

I'm not sure I understand why the background color and the content bounds are linked? Is there a tldr on that anywhere?

Background color shenanigans notwithstanding, this PR seems correct to me.

[andreasdj]

When testing the behavior of the rendering with the gist that has been referenced in many of the issues/PR:s related to the background color changes I see the same behavior in rendering independent of this change.

Gist: https://gist.github.com/ddramone/712a2fde2757736c9dbf6c3e7e0aa18b.
Updated gist: https://gist.github.com/andreasdj/f33865f96f621d3695bf902e564aca4d (adds the BrowserViews on the main window 'ready-to-show' event to always have them rendered).

Electron 17.1.2 (using Electron Fiddle):

Electron 18.0.0-nightly.20220201 (using the build output of the current branch):

[codebytere]

hmm @andreasdj it appears to have regressed again via Chromium update. Let's fix this for now and look into a better solution for the initial issue.

[andreasdj]

Perfect @codebytere! I've always found that particular example a bit odd in the way the background color is set for the BrowserView.

It seems like a background color set on a page would take precedence so why not just set the background color on the rendered web page directly. If you are missing control over the page you could still do it using webContents.setCSS or with a preload script. I tested to set a half transparent background color on the BrowserView that's shifted outside of the view using webContents.setCSS and it worked nicely so at least there are a couple a ways to solve that issue.

Sorry for drifting away, keep up the good work!

[welcome]

Congrats on merging your first pull request! 🎉🎉🎉

[release-clerk]

Release Notes Persisted

Fixed an issue where BrowserView layout bounds where limited to it's visible bounds.

[trop]

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

[trop]

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