CODEWITHSUNDEEP
javascriptelectron
Ziyad Parekh
Ziyad Parekh

Reputation: 183

What is the difference between BrowserWindow and <Webview> Tag in electron and when is it advisable to use each?

Here are links to specific parts of the electron docs:

Browser Window

Webview Tag

(Edit) The use case I was thinking about is for example if I want to build a browser, would each webpage in a tab be an instance of a Webview or a BrowserWindow? Or for instance if I wanted to build a programming editor, and I wanted to display the rendered HTML page right next to the code, would that be a new BrowserWindow or a Webview?

Upvotes: 17

Views: 13440

Answers (3)

Elika Filin
Elika Filin

Reputation: 9

Electron 31 supports tabbed windows for MacOS: https://www.electronjs.org/docs/latest/api/browser-window#winaddtabbedwindowbrowserwindow-macos

we can combine with setWindowOpenHandler

Example:

    mainWindow.webContents.setWindowOpenHandler(() => {
    return {
      action: 'allow',
      createWindow: (options) => {
        const browserWindow = new BrowserWindow(options);
        mainWindow.addTabbedWindow(browserWindow);
        browserWindow.setBounds({ x: 0, y: 0, width: 640, height: 480 });
        return browserWindow.webContents;
      },
    };
  });

UPDATE:

I'll not suggest using it, because it has bottlenecks:

  1. Windows are nested: it means that when the user close tab which was the parent for some tabs - all tabs will be closed (parent tab and all child tabs)
  2. Add tab functionality not working and I didn't find how I can implement it or hidden plus icon

I've found tabs management implementation written on Swift, so I conduct that tabs management functionality didn't provide by MacOS in meaning like we habit in browser: docs. Maybe it is possible to extend in Swift, but not in Electron using JS or TS.

So, I implemented tabs functionality by using simple AntD Tabs.

Upvotes: 0

Mingzhong
Mingzhong

Reputation: 221

Electron 5 suggests using browserview/iframe instead of webview.
https://electronjs.org/docs/api/webview-tag

Upvotes: 2

Shawn Rakowski
Shawn Rakowski

Reputation: 5714

I can understand why it would be confusing on which of these to host your content in given their similarities. They both start in separate processes and have many similar configurations. The key difference between the BrowserWindow and the webview is that the BrowserWindow is a window on the platform and a webview is an element on an webpage This may be a bit of an obvious, superficial distinction, but much of their differences and usages derive from it.

Much of the reason a webview exists is to allow for untrusted content to be embedded within your application. If you read up on the use cases for the webview, a lot of them point to the fact that the BrowserWindow, by default, has complete access to the Node APIs. Hosting untrusted content within it is handing that content significant access to your system and presents a security concern. The webview, however, does not have Node integration turned on by default, and so it shields your application, and the platform, from the hosted content.

However, this distinction is a bit of a red herring as Node integration can be disabled on BrowserWindow and can be enabled on a webview element. That is to say, you should be able to safely host untrusted content in a BrowserWindow by taking away access to Node and host trusted content in a webview and provide it access to Node.

The key to the webview is that it allows the embedding of untrusted content on a webpage/view in your application. If, within the same view/page, you would like to have some content that is trusted with full access to Node APIs and some content that is untrusted and given limited or no access to Node APIs then this may only be accomplished with the webview element. It is a way to segregate and lock down a piece of a webpage hosted in a BrowserWindow while allowing the rest of it to be open.

Aside from embedding untrusted content, the only other case I can think of for using webviews over BrowserWindows is if you want to open and view multiple separate processes in a single window. An application could choose to create 10 different windows for 10 different processes and have the platform handle layout, focus, etc or it could open 1 window with 10 webviews for 10 different processes and handle the layout, focus, etc itself within that window.

(Edit) To address the edit to the question:

For both of these cases I would suggest using a webview.

In the first scenario, a browser, you mentioned "tabs". There is no easy, cross-platform method that I know of for building a tabbed applications using multiple BrowserWindows because the windows are created by the native OS. You could, however, achieve this by creating a tabbed application within a single webpage, each tab containing a webview. In this case you would want to ensure Node integration is disabled on the webview (it should be by default), since loading content from the web is generally untrusted.

The second scenario, an editor with rendered HTML, is not as clear cut. You could use a webview, an iframe, or render the content directly to a div. Rendering directly to a div may be the best option for something like Markdown or small snippets of HTML so long as you do not need custom css or want to execute JavaScript. It otherwise makes sense to use a webview or an iframe. The difference being that a webview starts in a separate process and may have Node integration or flexed security whereas an iframe is loaded within the same process as the BrowserWindow and, I think, has locked down security. Regardless, to get a side-by-side look without another window you need to use a HTML element like a webview and not a BrowserWindow.

Upvotes: 25

Related Questions