[Bug]: BrowserView broken since v13.5.0

[exander77]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Electron Version

13.5.0

What operating system are you using?

Ubuntu

Operating System Version

20.04

What arch are you using?

x64

Last Known Working Electron version

13.4.0

Expected Behavior

const win = new BrowserWindow({ width: 800, height: 600 })

const view = new BrowserView()
win.setBrowserView(view)
view.setBounds({ x: 0, y: 0, width: 300, height: 300 })
view.webContents.loadURL('https://electronjs.org')

Example from documentation should open BrowserWindow with BrowserView with electronjs.org website.

Actual Behavior

Everything stays blank.

Testcase Gist URL

No response

Additional Information

https://newbedev.com/electron/api/browser-view

Broken up to current v15.1.2.

Possibly related to: #31047

No response

[exander77]

I am using ElectronJS for around a month and a half, but I can't seem to get the hang of the problems with the project. I can't seem to select the appropriate version as for example silent print to a specific printer does not work in any supported version. And for example this issue. BrowserView is recommended over WebView, yet it does not work consistently, predictively or at all, see: https://www.electronjs.org/docs/latest/tutorial/web-embeds

[clavin]

Thanks for the report! I was able to reproduce this on Ubuntu 20.04. Here's a bit more information I dug up:

This seems to have broken between versions v14.0.0-nightly.20210413 and v14.0.0-nightly.20210426. The PR that broke it was also backported to the 13-x-y line which broke between versions v13.4.0 and v13.5.0.

I confirmed that #31047 did not cause this bug.

I actually narrowed it down to #30887, which is a backport of #29600, which causes this bug.

[exander77]

Great work narrowing it to actual PR. Btw, one in 100 attempts or so, the BrowserView actually rendered for me. That's when I started digging that maybe my code is actually ok.

[stjava]

i have this problem too

[SpacingBat3]

Great work narrowing it to actual PR. Btw, one in 100 attempts or so, the BrowserView actually rendered for me. That's when I started digging that maybe my code is actually ok.

From my tests, BrowserView is unable to set its bounds unless there's some timeout for the window to appear – that could be why it does work in some cases when BrowserView is ready to be able to change its bounds. I'm still not certainly sure what exactly could cause this bug, but as the workaround the one could just set the bounds of the BrowserView after some timeout to increase its chance to load properly.

For an example, a patch for the BrowserView example code in Electron Fiddle could be like:

24c24
<   view.setBounds({ x: 0, y: 0, width: 300, height: 300 })
---
>   view.webContents.on("did-finish-load", () => view.setBounds({ x: 0, y: 0, width: 300, height: 300 }))

This will make the view to set its bounds after the page loads.

[estepona]

Great work narrowing it to actual PR. Btw, one in 100 attempts or so, the BrowserView actually rendered for me. That's when I started digging that maybe my code is actually ok.

From my tests, BrowserView is unable to set its bounds unless there's some timeout for the window to appear – that could be why it does work in some cases when BrowserView is ready to be able to change its bounds. I'm still not certainly sure what exactly could cause this bug, but as the workaround the one could just set the bounds of the BrowserView after some timeout to increase its chance to load properly.

For an example, a patch for the BrowserView example code in Electron Fiddle could be like:

24c24
<   view.setBounds({ x: 0, y: 0, width: 300, height: 300 })
---
>   view.webContents.on("did-finish-load", () => view.setBounds({ x: 0, y: 0, width: 300, height: 300 }))

This will make the view to set its bounds after the page loads.

I can confirm the original issue persists in electron v19.0.10. electron.org works fine, but google.com wouldn't work. The above answer solves the problem for me.

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

[SebastienWae]

bump!

This issue is still affecting me on Linux, but I can't reproduce it on macos.

[Hinaser]

I mitigated this issue by defering page load as follows.

const win = new BrowserWindow({ width: 800, height: 600 })

const view = new BrowserView()
win.setBrowserView(view)
view.setBounds({ x: 0, y: 0, width: 300, height: 300 })
// Move 'loadURL' execution to another event loop context.
setTimeout(() => view.webContents.loadURL('https://electronjs.org'), 0);

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

[github-actions]

This issue has been closed due to inactivity, and will not be monitored. If this is a bug and you can reproduce this issue on a supported version of Electron please open a new issue and include instructions for reproducing the issue.

[akshay-aravind]

I am getting this issue with the latest electron version.

[j0hnm4r5]

I too am still getting this issue in v25.3.2, on Ubuntu 20.04. The setInterval trick does not seem to work, at least for me.

[safinaskar]

Original bug ( #31424 (comment) ) still reproducible with Node 18.13, Electron 26.2, recent Debian Linux sid and with wikipedia.org as test page.

Workaround in #31424 (comment) still works