The fate of BrowserView

[zeke]

I heard some murmurs at our recent Tokyo mini-summit that an upcoming version of Chrome will address whatever problems Electron's BrowserView API was created to solve. Is it Chromium 61? Does that mean that we should deprecate BrowserView when Chromium 61 lands in Electron?

cc @electron/browserview @poiru @felixrieseberg

[poiru]

I don't think so. <webview> still has a number of bugs. There are also architectural issues like slow auto-resizing that are unlikely to be fixed in Chromium any time soon.

Out of curiosity, do you recall any details from the murmurs?

[deepak1556]

Chromium 61 lands OOPIF (actually its already available behind a flag), its an architectural change in how webview works. We need to implement it in Electron and its quite some work. I don't think we would want to deprecate BrowserView for it.

[zeke]

do you recall any details

No I don't have any details; just heard people talking about it in passing. Apparently Slack is using BrowserView but they think they'll be able to switch back to webviews in Chromium 61.

[CharlieHess]

I'm going to have to disagree with any plans (on Slack's end) to switch back to webview (at least anytime soon). Admittedly we haven't shipped our release with BrowserView yet, but all early signs point to it being much more reliable than webview. Unless we find a new set of problems with BrowserView, there'd really be no good reason to rearrange all our code a second time.

[TimNZ]

For the rest of us mortals is there a summary (bullet point is fine) of why/when BrowserView should be used over BrowserWindow? Top 3-5 list would do the job, a when and when not to use..

I am building an app which uses a lot of webview and am finding issues that maybe can be worked around or just tolerated for the time being, and have no idea if BrowserView would address them.

For example, if this still applies then BrowserView is pretty useless to me: #10323 (one BrowserView per BrowserWindow)

Thanks

[TimNZ]

https://www.chromium.org/developers/design-documents/oop-iframes

"It is worth noting that the implementation is being migrated to work on top of the new OOPIF infrastructure."

[felixrieseberg]

@TimNZ That "one per window" rule still applies. In general, WebViews are embedded into your DOM (using browser plugin architecture). BrowserViews on the other hand are simply another renderer glued on top of your existing window.

They come with different issues. WebViews are part of the whole ecosystem and easier to work with, but any bugs will be low-level. We've found issues with navigation, rendering, and composition. All in small fractions of our overall userbase, but enough to go with BrowserViews. They are primitive and dumb, tough to work with, and unforgiving when it comes to cooperation with the underlying window.

[zeke]

For the rest of us mortals is there a summary (bullet point is fine) of why/when BrowserView should be used over BrowserWindow? Top 3-5 list would do the job, a when and when not to use..

@TimNZ this would be great.

In the absence of such a list, this article by @poiru may help shed some light on the differences: https://blog.figma.com/introducing-browserview-for-electron-7b40b4b493d5

[TimNZ]

Thanks @zeke @felixrieseberg, helpful.

I am building a 'browser' so using a lot of simultaneous webview in a BrowserWindow.
Found some quirks that are likely not show stoppers for my users (starting trials very shortly) today, but need to be addressed (IPC via sendToHost has issues for example when trying to automate multiple webview simultaneously for example)

Brave managed to build a high usage product around webview (Muon) so I have to presume they either found no major blockers, or did their own minor fixes.

Likely tradeoffs that don't affect me badly, but were enough of an issue for Figma to build BrowserView.

[skllcrn]

The new Slack beta is basically a complete rewrite of their Electron app to jump from WebView to BrowserView https://slack.engineering/growing-pains-migrating-slacks-desktop-app-to-browserview-2759690d9c7b

[TimNZ]

@CharlieHess, I asked a question on the medium post:

https://medium.com/@SuperWorker/electron-query-only-one-browserview-is-supported-in-a-browserwindow-what-are-the-main-632c96d0cd77

Can we get more insights into what it would take to replace webview with BrowserView and top drivers/issues?

I am writing a browser replacement, so has Brave (with Muon), Station (getstation.com), and others.
What are the things we should know about and consider if we decide to do a switch?

Thanks for any guidance you can provide.

[ibash]

Implementing #10323 would be amazing.

Without that one limitation of BrowserView is that you can't implement findInPage UI wherever you like. Right now if you put an input in the BrowserView and call findInPage the input text is also highlighted, so you're restricted to putting the UI outside of the BrowserView or putting it in a child window.

[hevilp]

That would be very nice, I', using 4 webview tags in 1 browser window und would like to change it doe BrowserView.

[Tim91084]

I've been trying out BrowserView for one of the projects I'm working on. One of the drawbacks, at least as far as I can tell, is that you can't layer anything on top of a BrowserView. For instance, if you have a dropdown menu in the BrowserWindow which hosts the BrowserView, you can't layer that menu on top of the BrowserView. I see that #9166 mentions adding z-ordering. That would be a killer feature. I wonder if anyone is working on it...

[dtaipov]

7/30/18 a warning https://github.com/electron/electron/blob/master/docs/api/webview-tag.md#warning added to the webview tag documentation:

Electron's webview tag is based on Chromium's webview, which is undergoing dramatic architectural changes. This impacts the stability of webviews, including rendering, navigation, and event routing. We currently recommend to not use the webview tag and to consider alternatives, like iframe, Electron's BrowserView, or an architecture that avoids embedded content altogether.

Correspondent pull request: #13835

So right now, it' oposite, Electron team is recommending to use BrowserView in favor of webview tag.

[ccnokes]

I just read the warning in the docs on webview and the associated PR (#13835). When do these big architectural changes to webview land in Chrome? Is there a rough idea on when webviews will be deprecated (as mentioned in that PR)?

[hevilp]

There are some news?It is possible to have more than 1 BrowserView in a BrowserWindow?

[milanify]

There are some news?It is possible to have more than 1 BrowserView in a BrowserWindow?

As of right now, no. If you try loading two BrowserViews in the same BrowserWindow, only your last called BrowserView will appear, meaning in this case your first BrowserView will not show up but your second one will.

[felipemullen]

You can in fact load more than one BrowserView objects into a BrowserWindow by using BrowserWindow.addBrowserView() instead of setBrowserView()

see https://stackoverflow.com/questions/55029098/why-does-only-one-browserview-work-with-electron/55030940#55030940

[xiaosu12138]

There are some news?It is possible to have more than 1 BrowserView in a BrowserWindow?

As of right now, no. If you try loading two BrowserViews in the same BrowserWindow, only your last called BrowserView will appear, meaning in this case your first BrowserView will not show up but your second one will.

any idea how to show the first BrowserView ?

[miniak]

Thanks for reaching out!

The issues tracker is used for feature requests and bug reports, so you will probably have better luck with this question at one of the links at the project's Community page -- in particular, be sure to give the Electron Discord server a try.

I hope this helps!