electron/spec-main/api-browser-view-spec.ts

250 строки
7.1 KiB
TypeScript
Исходник Обычный вид История

import { expect } from 'chai'
import * as ChildProcess from 'child_process'
import * as path from 'path'
import { emittedOnce } from './events-helpers'
import { BrowserView, BrowserWindow } from 'electron'
2019-11-01 23:37:02 +03:00
import { closeWindow } from './window-helpers'
2017-10-27 03:11:12 +03:00
describe('BrowserView module', () => {
const fixtures = path.resolve(__dirname, '..', 'spec', 'fixtures')
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 20:47:30 +03:00
2017-10-27 03:05:15 +03:00
beforeEach(() => {
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 20:47:30 +03:00
w = new BrowserWindow({
show: false,
width: 400,
height: 400,
webPreferences: {
backgroundThrottling: false
}
})
})
afterEach(async () => {
await closeWindow(w)
2017-04-13 00:52:07 +03:00
if (view) {
view.destroy()
}
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 20:47:30 +03:00
})
describe('BrowserView.destroy()', () => {
it('does not throw', () => {
view = new BrowserView()
view.destroy()
})
})
describe('BrowserView.isDestroyed()', () => {
it('returns correct value', () => {
view = new BrowserView()
expect(view.isDestroyed()).to.be.false('view is destroyed')
view.destroy()
expect(view.isDestroyed()).to.be.true('view is destroyed')
})
})
2017-10-27 03:05:15 +03:00
describe('BrowserView.setBackgroundColor()', () => {
it('does not throw for valid args', () => {
2017-04-13 00:52:07 +03: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 20:47:30 +03:00
view.setBackgroundColor('#000')
})
2017-10-27 03:05:15 +03:00
it('throws for invalid args', () => {
2017-04-13 00:52:07 +03:00
view = new BrowserView()
expect(() => {
view.setBackgroundColor(null as any)
}).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 20:47:30 +03:00
})
})
2017-10-27 03:05:15 +03:00
describe('BrowserView.setAutoResize()', () => {
it('does not throw for valid args', () => {
2017-04-13 00:52:07 +03:00
view = new BrowserView()
view.setAutoResize({})
view.setAutoResize({ width: true, height: false })
})
2017-10-27 03:05:15 +03:00
it('throws for invalid args', () => {
2017-04-13 00:52:07 +03:00
view = new BrowserView()
expect(() => {
view.setAutoResize(null as any)
}).to.throw(/conversion failure/)
})
})
2017-10-27 03:05:15 +03:00
describe('BrowserView.setBounds()', () => {
it('does not throw for valid args', () => {
2017-04-13 00:52:07 +03: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 20:47:30 +03:00
view.setBounds({ x: 0, y: 0, width: 1, height: 1 })
})
2017-10-27 03:05:15 +03:00
it('throws for invalid args', () => {
2017-04-13 00:52:07 +03:00
view = new BrowserView()
expect(() => {
view.setBounds(null as any)
}).to.throw(/conversion failure/)
expect(() => {
view.setBounds({} as any)
}).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 20:47:30 +03: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 03:05:15 +03:00
describe('BrowserWindow.setBrowserView()', () => {
it('does not throw for valid args', () => {
2017-04-13 00:52:07 +03: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 20:47:30 +03:00
w.setBrowserView(view)
})
2017-10-27 03:05:15 +03:00
it('does not throw if called multiple times with same view', () => {
2017-04-13 00:52:07 +03: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 20:47:30 +03:00
w.setBrowserView(view)
w.setBrowserView(view)
w.setBrowserView(view)
})
})
2017-10-27 21:44:41 +03:00
describe('BrowserWindow.getBrowserView()', () => {
it('returns the set view', () => {
view = new BrowserView()
w.setBrowserView(view)
expect(view.id).to.not.be.null('view id')
const view2 = w.getBrowserView()
expect(view2!.webContents.id).to.equal(view.webContents.id)
2017-10-27 21:44:41 +03:00
})
it('returns null if none is set', () => {
const view = w.getBrowserView()
expect(view).to.be.null('view')
2017-10-27 21:44:41 +03:00
})
})
describe('BrowserWindow.addBrowserView()', () => {
it('does not throw for valid args', () => {
const view1 = new BrowserView()
w.addBrowserView(view1)
const view2 = new BrowserView()
w.addBrowserView(view2)
view1.destroy()
view2.destroy()
})
it('does not throw if called multiple times with same view', () => {
view = new BrowserView()
w.addBrowserView(view)
w.addBrowserView(view)
w.addBrowserView(view)
})
})
describe('BrowserWindow.removeBrowserView()', () => {
it('does not throw if called multiple times with same view', () => {
view = new BrowserView()
w.addBrowserView(view)
w.removeBrowserView(view)
w.removeBrowserView(view)
})
})
describe('BrowserWindow.getBrowserViews()', () => {
it('returns same views as was added', () => {
const view1 = new BrowserView()
w.addBrowserView(view1)
const view2 = new BrowserView()
w.addBrowserView(view2)
expect(view1.id).to.be.not.null('view id')
const views = w.getBrowserViews()
expect(views).to.have.lengthOf(2)
expect(views[0].webContents.id).to.equal(view1.webContents.id)
expect(views[1].webContents.id).to.equal(view2.webContents.id)
view1.destroy()
view2.destroy()
})
})
2017-10-27 03:05:15 +03:00
describe('BrowserView.webContents.getOwnerBrowserWindow()', () => {
it('points to owning window', () => {
view = new BrowserView()
expect(view.webContents.getOwnerBrowserWindow()).to.be.null('owner browser window')
w.setBrowserView(view)
expect(view.webContents.getOwnerBrowserWindow()).to.equal(w)
w.setBrowserView(null)
expect(view.webContents.getOwnerBrowserWindow()).to.be.null('owner browser window')
})
})
2017-07-24 06:32:30 +03:00
2017-10-27 03:05:15 +03:00
describe('BrowserView.fromId()', () => {
it('returns the view with given id', () => {
2017-07-24 06:32:30 +03:00
view = new BrowserView()
w.setBrowserView(view)
expect(view.id).to.not.be.null('view id')
const view2 = BrowserView.fromId(view.id)
expect(view2.webContents.id).to.equal(view.webContents.id)
2017-07-24 06:32:30 +03:00
})
})
2017-11-23 04:06:14 +03:00
describe('BrowserView.fromWebContents()', () => {
it('returns the view with given id', () => {
view = new BrowserView()
w.setBrowserView(view)
expect(view.id).to.not.be.null('view id')
const view2 = BrowserView.fromWebContents(view.webContents)
expect(view2!.webContents.id).to.equal(view.webContents.id)
2017-11-23 04:06:14 +03:00
})
})
describe('BrowserView.getAllViews()', () => {
it('returns all views', () => {
view = new BrowserView()
w.setBrowserView(view)
expect(view.id).to.not.be.null('view id')
2017-11-23 04:06:14 +03:00
const views = BrowserView.getAllViews()
expect(views).to.be.an('array').that.has.lengthOf(1)
expect(views[0].webContents.id).to.equal(view.webContents.id)
2017-11-23 04:06:14 +03:00
})
})
describe('new BrowserView()', () => {
it('does not crash on exit', async () => {
const appPath = path.join(__dirname, 'fixtures', 'api', 'leak-exit-browserview.js')
const electronPath = process.execPath
const appProcess = ChildProcess.spawn(electronPath, [appPath])
const [code] = await emittedOnce(appProcess, 'close')
expect(code).to.equal(0)
})
})
describe('window.open()', () => {
it('works in BrowserView', (done) => {
view = new BrowserView()
w.setBrowserView(view)
view.webContents.once('new-window', (e, url, frameName, disposition, options, additionalFeatures) => {
e.preventDefault()
expect(url).to.equal('http://host/')
expect(frameName).to.equal('host')
expect(additionalFeatures[0]).to.equal('this-is-not-a-standard-feature')
done()
})
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 20:47:30 +03:00
})