2019-11-07 00:15:55 +00:00
|
|
|
import { expect } from 'chai';
|
2019-07-24 15:44:24 +00:00
|
|
|
import * as path from 'path';
|
|
|
|
import { emittedOnce } from './events-helpers';
|
2020-07-09 15:48:39 +00:00
|
|
|
import { BrowserView, BrowserWindow, webContents } from 'electron/main';
|
2019-11-01 20:37:02 +00:00
|
|
|
import { closeWindow } from './window-helpers';
|
2020-07-09 15:48:39 +00:00
|
|
|
import { defer, startRemoteControlApp } from './spec-helpers';
|
2019-08-06 17:27:33 +00:00
|
|
|
|
2017-10-27 00:11:12 +00:00
|
|
|
describe('BrowserView module', () => {
|
2019-07-24 15:44:24 +00:00
|
|
|
const fixtures = path.resolve(__dirname, '..', 'spec', 'fixtures');
|
2018-11-27 01:39:03 +00:00
|
|
|
|
2019-07-24 15:44:24 +00:00
|
|
|
let w: BrowserWindow;
|
|
|
|
let view: BrowserView;
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
|
2017-10-27 00:05:15 +00:00
|
|
|
beforeEach(() => {
|
2020-07-09 15:48:39 +00:00
|
|
|
expect(webContents.getAllWebContents()).to.have.length(0);
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
w = new BrowserWindow({
|
|
|
|
show: false,
|
|
|
|
width: 400,
|
|
|
|
height: 400,
|
|
|
|
webPreferences: {
|
|
|
|
backgroundThrottling: false
|
|
|
|
}
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2019-07-24 15:44:24 +00:00
|
|
|
afterEach(async () => {
|
2020-07-09 15:48:39 +00:00
|
|
|
const p = emittedOnce(w.webContents, 'destroyed');
|
2019-10-04 00:30:44 +00:00
|
|
|
await closeWindow(w);
|
2020-07-09 15:48:39 +00:00
|
|
|
w = null as any;
|
|
|
|
await p;
|
2019-10-04 00:30:44 +00:00
|
|
|
|
2017-04-12 21:52:07 +00:00
|
|
|
if (view) {
|
2020-07-09 15:48:39 +00:00
|
|
|
const p = emittedOnce(view.webContents, 'destroyed');
|
|
|
|
(view.webContents as any).destroy();
|
|
|
|
view = null as any;
|
|
|
|
await p;
|
2017-04-12 21:52:07 +00:00
|
|
|
}
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
|
2020-07-09 15:48:39 +00:00
|
|
|
expect(webContents.getAllWebContents()).to.have.length(0);
|
2018-03-15 07:15:56 +00:00
|
|
|
});
|
|
|
|
|
2020-12-15 23:52:43 +00:00
|
|
|
it('can be created with an existing webContents', async () => {
|
|
|
|
const wc = (webContents as any).create({ sandbox: true });
|
|
|
|
await wc.loadURL('about:blank');
|
|
|
|
|
|
|
|
view = new BrowserView({ webContents: wc } as any);
|
|
|
|
|
|
|
|
expect(view.webContents.getURL()).to.equal('about:blank');
|
|
|
|
});
|
|
|
|
|
2017-10-27 00:05:15 +00:00
|
|
|
describe('BrowserView.setBackgroundColor()', () => {
|
|
|
|
it('does not throw for valid args', () => {
|
2017-04-12 21:52:07 +00:00
|
|
|
view = new BrowserView();
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
view.setBackgroundColor('#000');
|
|
|
|
});
|
|
|
|
|
2017-10-27 00:05:15 +00:00
|
|
|
it('throws for invalid args', () => {
|
2017-04-12 21:52:07 +00:00
|
|
|
view = new BrowserView();
|
2018-06-17 22:56:04 +00:00
|
|
|
expect(() => {
|
2019-07-24 15:44:24 +00:00
|
|
|
view.setBackgroundColor(null as any);
|
2018-06-17 22:56:04 +00:00
|
|
|
}).to.throw(/conversion failure/);
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2017-10-27 00:05:15 +00:00
|
|
|
describe('BrowserView.setAutoResize()', () => {
|
|
|
|
it('does not throw for valid args', () => {
|
2017-04-12 21:52:07 +00:00
|
|
|
view = new BrowserView();
|
2017-04-12 11:40:31 +00:00
|
|
|
view.setAutoResize({});
|
|
|
|
view.setAutoResize({ width: true, height: false });
|
|
|
|
});
|
|
|
|
|
2017-10-27 00:05:15 +00:00
|
|
|
it('throws for invalid args', () => {
|
2017-04-12 21:52:07 +00:00
|
|
|
view = new BrowserView();
|
2018-06-17 22:56:04 +00:00
|
|
|
expect(() => {
|
2019-07-24 15:44:24 +00:00
|
|
|
view.setAutoResize(null as any);
|
2018-06-17 22:56:04 +00:00
|
|
|
}).to.throw(/conversion failure/);
|
2017-04-12 11:40:31 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2017-10-27 00:05:15 +00:00
|
|
|
describe('BrowserView.setBounds()', () => {
|
|
|
|
it('does not throw for valid args', () => {
|
2017-04-12 21:52:07 +00:00
|
|
|
view = new BrowserView();
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
view.setBounds({ x: 0, y: 0, width: 1, height: 1 });
|
|
|
|
});
|
|
|
|
|
2017-10-27 00:05:15 +00:00
|
|
|
it('throws for invalid args', () => {
|
2017-04-12 21:52:07 +00:00
|
|
|
view = new BrowserView();
|
2018-06-17 22:56:04 +00:00
|
|
|
expect(() => {
|
2019-07-24 15:44:24 +00:00
|
|
|
view.setBounds(null as any);
|
2018-06-17 22:56:04 +00:00
|
|
|
}).to.throw(/conversion failure/);
|
|
|
|
expect(() => {
|
2019-07-24 15:44:24 +00:00
|
|
|
view.setBounds({} as any);
|
2018-06-17 22:56:04 +00:00
|
|
|
}).to.throw(/conversion failure/);
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2019-07-30 02:43:05 +00:00
|
|
|
describe('BrowserView.getBounds()', () => {
|
|
|
|
it('returns the current bounds', () => {
|
|
|
|
view = new BrowserView();
|
|
|
|
const bounds = { x: 10, y: 20, width: 30, height: 40 };
|
|
|
|
view.setBounds(bounds);
|
|
|
|
expect(view.getBounds()).to.deep.equal(bounds);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2017-10-27 00:05:15 +00:00
|
|
|
describe('BrowserWindow.setBrowserView()', () => {
|
|
|
|
it('does not throw for valid args', () => {
|
2017-04-12 21:52:07 +00:00
|
|
|
view = new BrowserView();
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
w.setBrowserView(view);
|
|
|
|
});
|
|
|
|
|
2017-10-27 00:05:15 +00:00
|
|
|
it('does not throw if called multiple times with same view', () => {
|
2017-04-12 21:52:07 +00:00
|
|
|
view = new BrowserView();
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
w.setBrowserView(view);
|
|
|
|
w.setBrowserView(view);
|
|
|
|
w.setBrowserView(view);
|
|
|
|
});
|
|
|
|
});
|
2017-06-21 23:21:28 +00:00
|
|
|
|
2017-10-27 18:44:41 +00:00
|
|
|
describe('BrowserWindow.getBrowserView()', () => {
|
|
|
|
it('returns the set view', () => {
|
|
|
|
view = new BrowserView();
|
|
|
|
w.setBrowserView(view);
|
2018-06-17 22:56:04 +00:00
|
|
|
|
2018-10-02 01:56:31 +00:00
|
|
|
const view2 = w.getBrowserView();
|
2019-07-24 15:44:24 +00:00
|
|
|
expect(view2!.webContents.id).to.equal(view.webContents.id);
|
2017-10-27 18:44:41 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
it('returns null if none is set', () => {
|
2018-10-02 01:56:31 +00:00
|
|
|
const view = w.getBrowserView();
|
2019-07-24 15:44:24 +00:00
|
|
|
expect(view).to.be.null('view');
|
2017-10-27 18:44:41 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2018-12-22 01:49:26 +00:00
|
|
|
describe('BrowserWindow.addBrowserView()', () => {
|
|
|
|
it('does not throw for valid args', () => {
|
2019-07-24 15:44:24 +00:00
|
|
|
const view1 = new BrowserView();
|
2020-07-09 15:48:39 +00:00
|
|
|
defer(() => (view1.webContents as any).destroy());
|
2018-12-22 01:49:26 +00:00
|
|
|
w.addBrowserView(view1);
|
2020-07-09 15:48:39 +00:00
|
|
|
defer(() => w.removeBrowserView(view1));
|
2019-07-24 15:44:24 +00:00
|
|
|
const view2 = new BrowserView();
|
2020-07-09 15:48:39 +00:00
|
|
|
defer(() => (view2.webContents as any).destroy());
|
2018-12-22 01:49:26 +00:00
|
|
|
w.addBrowserView(view2);
|
2020-07-09 15:48:39 +00:00
|
|
|
defer(() => w.removeBrowserView(view2));
|
2018-12-22 01:49:26 +00:00
|
|
|
});
|
2020-08-26 03:04:13 +00:00
|
|
|
|
2018-12-22 01:49:26 +00:00
|
|
|
it('does not throw if called multiple times with same view', () => {
|
|
|
|
view = new BrowserView();
|
|
|
|
w.addBrowserView(view);
|
|
|
|
w.addBrowserView(view);
|
|
|
|
w.addBrowserView(view);
|
|
|
|
});
|
2020-08-26 03:04:13 +00:00
|
|
|
|
2021-11-15 07:24:22 +00:00
|
|
|
it('does not crash if the BrowserView webContents are destroyed prior to window addition', () => {
|
2020-08-26 03:04:13 +00:00
|
|
|
expect(() => {
|
|
|
|
const view1 = new BrowserView();
|
|
|
|
(view1.webContents as any).destroy();
|
|
|
|
w.addBrowserView(view1);
|
|
|
|
}).to.not.throw();
|
|
|
|
});
|
2021-01-05 00:34:22 +00:00
|
|
|
|
2021-11-15 07:24:22 +00:00
|
|
|
it('does not crash if the webContents is destroyed after a URL is loaded', () => {
|
|
|
|
view = new BrowserView();
|
|
|
|
expect(async () => {
|
|
|
|
view.setBounds({ x: 0, y: 0, width: 400, height: 300 });
|
|
|
|
await view.webContents.loadURL('data:text/html,hello there');
|
|
|
|
view.webContents.destroy();
|
|
|
|
}).to.not.throw();
|
|
|
|
});
|
|
|
|
|
2021-01-05 00:34:22 +00:00
|
|
|
it('can handle BrowserView reparenting', async () => {
|
|
|
|
view = new BrowserView();
|
|
|
|
|
|
|
|
w.addBrowserView(view);
|
|
|
|
view.webContents.loadURL('about:blank');
|
|
|
|
await emittedOnce(view.webContents, 'did-finish-load');
|
|
|
|
|
|
|
|
const w2 = new BrowserWindow({ show: false });
|
|
|
|
w2.addBrowserView(view);
|
|
|
|
|
|
|
|
w.close();
|
|
|
|
|
|
|
|
view.webContents.loadURL(`file://${fixtures}/pages/blank.html`);
|
|
|
|
await emittedOnce(view.webContents, 'did-finish-load');
|
|
|
|
|
|
|
|
// Clean up - the afterEach hook assumes the webContents on w is still alive.
|
|
|
|
w = new BrowserWindow({ show: false });
|
|
|
|
w2.close();
|
|
|
|
w2.destroy();
|
|
|
|
});
|
2018-12-22 01:49:26 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
describe('BrowserWindow.removeBrowserView()', () => {
|
|
|
|
it('does not throw if called multiple times with same view', () => {
|
2020-08-26 03:04:13 +00:00
|
|
|
expect(() => {
|
|
|
|
view = new BrowserView();
|
|
|
|
w.addBrowserView(view);
|
|
|
|
w.removeBrowserView(view);
|
|
|
|
w.removeBrowserView(view);
|
|
|
|
}).to.not.throw();
|
2018-12-22 01:49:26 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
describe('BrowserWindow.getBrowserViews()', () => {
|
|
|
|
it('returns same views as was added', () => {
|
2019-07-24 15:44:24 +00:00
|
|
|
const view1 = new BrowserView();
|
2020-07-09 15:48:39 +00:00
|
|
|
defer(() => (view1.webContents as any).destroy());
|
2018-12-22 01:49:26 +00:00
|
|
|
w.addBrowserView(view1);
|
2020-07-09 15:48:39 +00:00
|
|
|
defer(() => w.removeBrowserView(view1));
|
2019-07-24 15:44:24 +00:00
|
|
|
const view2 = new BrowserView();
|
2020-07-09 15:48:39 +00:00
|
|
|
defer(() => (view2.webContents as any).destroy());
|
2018-12-22 01:49:26 +00:00
|
|
|
w.addBrowserView(view2);
|
2020-07-09 15:48:39 +00:00
|
|
|
defer(() => w.removeBrowserView(view2));
|
2020-03-20 20:28:31 +00:00
|
|
|
|
2018-12-22 01:49:26 +00:00
|
|
|
const views = w.getBrowserViews();
|
2019-05-20 17:04:18 +00:00
|
|
|
expect(views).to.have.lengthOf(2);
|
2018-12-22 01:49:26 +00:00
|
|
|
expect(views[0].webContents.id).to.equal(view1.webContents.id);
|
|
|
|
expect(views[1].webContents.id).to.equal(view2.webContents.id);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2021-02-10 07:23:35 +00:00
|
|
|
describe('BrowserWindow.setTopBrowserView()', () => {
|
|
|
|
it('should throw an error when a BrowserView is not attached to the window', () => {
|
|
|
|
view = new BrowserView();
|
|
|
|
expect(() => {
|
|
|
|
w.setTopBrowserView(view);
|
|
|
|
}).to.throw(/is not attached/);
|
|
|
|
});
|
|
|
|
|
|
|
|
it('should throw an error when a BrowserView is attached to some other window', () => {
|
|
|
|
view = new BrowserView();
|
|
|
|
|
|
|
|
const win2 = new BrowserWindow();
|
|
|
|
|
|
|
|
w.addBrowserView(view);
|
|
|
|
view.setBounds({ x: 0, y: 0, width: 100, height: 100 });
|
|
|
|
win2.addBrowserView(view);
|
|
|
|
|
|
|
|
expect(() => {
|
|
|
|
w.setTopBrowserView(view);
|
|
|
|
}).to.throw(/is not attached/);
|
|
|
|
|
|
|
|
win2.close();
|
|
|
|
win2.destroy();
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2017-10-27 00:05:15 +00:00
|
|
|
describe('BrowserView.webContents.getOwnerBrowserWindow()', () => {
|
|
|
|
it('points to owning window', () => {
|
2017-06-21 23:21:28 +00:00
|
|
|
view = new BrowserView();
|
2019-07-24 15:44:24 +00:00
|
|
|
expect(view.webContents.getOwnerBrowserWindow()).to.be.null('owner browser window');
|
2018-06-17 22:56:04 +00:00
|
|
|
|
2017-06-21 23:21:28 +00:00
|
|
|
w.setBrowserView(view);
|
2018-06-17 22:56:04 +00:00
|
|
|
expect(view.webContents.getOwnerBrowserWindow()).to.equal(w);
|
|
|
|
|
2017-06-21 23:21:28 +00:00
|
|
|
w.setBrowserView(null);
|
2019-07-24 15:44:24 +00:00
|
|
|
expect(view.webContents.getOwnerBrowserWindow()).to.be.null('owner browser window');
|
2017-06-21 23:21:28 +00:00
|
|
|
});
|
|
|
|
});
|
2017-07-24 03:32:30 +00:00
|
|
|
|
2020-07-09 15:48:39 +00:00
|
|
|
describe('shutdown behavior', () => {
|
|
|
|
it('does not crash on exit', async () => {
|
|
|
|
const rc = await startRemoteControlApp();
|
|
|
|
await rc.remotely(() => {
|
|
|
|
const { BrowserView, app } = require('electron');
|
|
|
|
new BrowserView({}) // eslint-disable-line
|
|
|
|
setTimeout(() => {
|
|
|
|
app.quit();
|
|
|
|
});
|
|
|
|
});
|
|
|
|
const [code] = await emittedOnce(rc.process, 'exit');
|
|
|
|
expect(code).to.equal(0);
|
2017-11-23 01:06:14 +00:00
|
|
|
});
|
2018-11-08 15:57:28 +00:00
|
|
|
|
2020-07-09 15:48:39 +00:00
|
|
|
it('does not crash on exit if added to a browser window', async () => {
|
|
|
|
const rc = await startRemoteControlApp();
|
|
|
|
await rc.remotely(() => {
|
|
|
|
const { app, BrowserView, BrowserWindow } = require('electron');
|
|
|
|
const bv = new BrowserView();
|
|
|
|
bv.webContents.loadURL('about:blank');
|
|
|
|
const bw = new BrowserWindow({ show: false });
|
|
|
|
bw.addBrowserView(bv);
|
|
|
|
setTimeout(() => {
|
|
|
|
app.quit();
|
|
|
|
});
|
|
|
|
});
|
|
|
|
const [code] = await emittedOnce(rc.process, 'exit');
|
2018-11-08 15:57:28 +00:00
|
|
|
expect(code).to.equal(0);
|
|
|
|
});
|
|
|
|
});
|
2018-11-27 01:39:03 +00:00
|
|
|
|
|
|
|
describe('window.open()', () => {
|
2020-11-10 17:06:03 +00:00
|
|
|
it('works in BrowserView', (done) => {
|
2018-11-27 01:39:03 +00:00
|
|
|
view = new BrowserView();
|
|
|
|
w.setBrowserView(view);
|
2020-11-10 17:06:03 +00:00
|
|
|
view.webContents.setWindowOpenHandler(({ url, frameName }) => {
|
|
|
|
expect(url).to.equal('http://host/');
|
|
|
|
expect(frameName).to.equal('host');
|
|
|
|
done();
|
|
|
|
return { action: 'deny' };
|
|
|
|
});
|
2018-11-27 01:39:03 +00:00
|
|
|
view.webContents.loadFile(path.join(fixtures, 'pages', 'window-open.html'));
|
|
|
|
});
|
|
|
|
});
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
});
|