Aller au contenu principal

Migrating from BrowserView to WebContentsView

· 4 mins de lecture

BrowserView has been deprecated since Electron 30 and is replaced by WebContentView. Thankfully, migrating is fairly painless.


Electron is moving from BrowserView to WebContentsView to align with Chromium’s UI framework, the Views API. WebContentsView offers a reusable view directly tied to Chromium’s rendering pipeline, simplifying future upgrades and opening up the possibility for developers to integrate non-web UI elements to their Electron apps. By adopting WebContentsView, applications are not only prepared for upcoming updates but also benefit from reduced code complexity and fewer potential bugs in the long run.

Developers familiar with BrowserWindows and BrowserViews should note that BrowserWindow and WebContentsView are subclasses inheriting from the BaseWindow and View base classes, respectively. To fully understand the available instance variables and methods, be sure to consult the documentation for these base classes.

Migration steps

1. Upgrade Electron to 30.0.0 or higher

avertissement

Electron releases may contain breaking changes that affect your application. It’s a good idea to test and land the Electron upgrade on your app first before proceeding with the rest of this migration. A list of breaking changes for each Electron major version can be found here as well as in the release notes for each major version on the Electron Blog.

2. Familiarize yourself with where your application uses BrowserViews

One way to do this is to search your codebase for new BrowserView(. This should give you a sense for how your application is using BrowserViews and how many call sites need to be migrated.

astuce

For the most part, each instance where your app instantiates new BrowserViews can be migrated in isolation from the others.

3. Migrate each usage of BrowserView

  1. Migrate the instantiation. This should be fairly straightforward because WebContentsView and BrowserView’s constructors have essentially the same shape. Both accept WebPreferences via the webPreferences param.

    - this.tabBar = new BrowserView({
    + this.tabBar = new WebContentsView({
    info

    By default, WebContentsView instantiates with a white background, while BrowserView instantiates with a transparent background. To get a transparent background in WebContentsView, set its background color to an RGBA hex value with an alpha (opaqueness) channel set to 00:

    + this.webContentsView.setBackgroundColor("#00000000");
  2. Migrate where the BrowserView gets added to its parent window.

    - this.browserWindow.addBrowserView(this.tabBar)
    + this.browserWindow.contentView.addChildView(this.tabBar);
  3. Migrate BrowserView instance method calls on the parent window.

    Old MethodNew MethodRemarques
    win.setBrowserViewwin.contentView.removeChildView + win.contentView.addChildView
    win.getBrowserViewwin.contentView.children
    win.removeBrowserViewwin.contentView.removeChildView
    win.setTopBrowserViewwin.contentView.addChildViewCalling addChildView on an existing view reorders it to the top.
    win.getBrowserViewswin.contentView.children
  4. Migrate the setAutoResize instance method to a resize listener.

    - this.browserView.setAutoResize({
    - vertical: true,
    - })

    + this.browserWindow.on('resize', () => {
    + if (!this.browserWindow || !this.webContentsView) {
    + return;
    + }
    + const bounds = this.browserWindow.getBounds();
    + this.webContentsView.setBounds({
    + x: 0,
    + y: 0,
    + width: bounds.width,
    + height: bounds.height,
    + });
    + });
    astuce

    All existing usage of browserView.webContents and instance methods browserView.setBounds, browserView.getBounds , and browserView.setBackgroundColor do not need to be migrated and should work with a WebContentsView instance out of the box!

4) Test and commit your changes

Running into issues? Check the WebContentsView tag on Electron's issue tracker to see if the issue you're encountering has been reported. If you don't see your issue there, feel free to add a new bug report. Including testcase gists will help us better triage your issue!

Congrats, you’ve migrated onto WebContentsViews! 🎉

Electron 33.0.0

· 5 mins de lecture

Electron 33.0.0 est disponible ! It includes upgrades to Chromium 130.0.6723.44, V8 13.0, and Node 20.18.0.


L’équipe Electron est heureuse d’annoncer la sortie d’Electron 33.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

Si vous avez des commentaires, veuillez les partager avec nous sur [Twitter] (https://twitter.com/electronjs) ou Mastodon, ou joignez-vous à notre communauté [Discord] (https://discord.com/invite/electronjs)! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables

  • Ajout d'un gestionnaire, app.setClientCertRequestPasswordHandler(handler), pour faciliter le déverrouillage des périphériques cryptographiques quand un code PIN est nécessaire. #41205
  • Extended navigationHistory API with 2 new functions for better history management. #42014
  • Improved native theme transparency checking. #42862

Introduction à l'historique de l'API (GSoC 2024)

· 8 mins de lecture

L'historique des changements des différentes API Electron sera maintenant détaillé dans la documentation.


Bonjour 👋, je suis Peter, le contributeur Electron pour le Google Summer of Code (GSoC).

Over the course of the GSoC program, I implemented an API history feature for the Electron documentation and its functions, classes, etc. in a similar fashion to the Node.js documentation: by allowing the use of a simple but powerful YAML schema in the API documentation Markdown files and displaying it nicely on the Electron documentation website.

Electron 32.0.0

· 5 mins de lecture

Electron 32.0.0 est disponible ! It includes upgrades to Chromium 128.0.6613.36, V8 12.8, and Node 20.16.0.


L’équipe Electron est heureuse d’annoncer la sortie d’Electron 32.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

Si vous avez des commentaires, veuillez les partager avec nous sur [Twitter] (https://twitter.com/electronjs) ou Mastodon, ou joignez-vous à notre communauté [Discord] (https://discord.com/invite/electronjs)! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables

  • Added new API version history in our documentation, a feature created by @piotrpdev as part of Google Summer of Code. You can learn more about it in this blog post. #42982
  • Removed nonstandard File.path extension from the Web File API. #42053
  • Aligned failure pathway in Web File System API with upstream when attempting to open a file or directory in a blocked path. #42993
  • Added the following existing navigation-related APIs to webcontents.navigationHistory: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear. The previous navigation APIs are now deprecated. #41752

Electron 31.0.0

· 4 mins de lecture

Electron 31.0.0 est disponible ! It includes upgrades to Chromium 126.0.6478.36, V8 12.6, and Node 20.14.0.


L’équipe Electron est heureuse d’annoncer la sortie d’Electron 31.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

Si vous avez des commentaires, veuillez les partager avec nous sur [Twitter] (https://twitter.com/electronjs) ou Mastodon, ou joignez-vous à notre communauté [Discord] (https://discord.com/invite/electronjs)! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables

  • Extended WebContentsView to accept pre-existing webContents object. #42319
  • Added support for NODE_EXTRA_CA_CERTS. #41689
  • Updated window.flashFrame(bool) to flash continuously on macOS. #41391
  • Removed WebSQL support #41868
  • nativeImage.toDataURL will preserve PNG colorspace #41610
  • Extended webContents.setWindowOpenHandler to support manual creation of BrowserWindow. #41432

Electron 30.0.0

· 5 mins de lecture

Electron 30.0.0 est disponible ! It includes upgrades to Chromium 124.0.6367.49, V8 12.4, and Node.js 20.11.1.


L’équipe Electron est heureuse d’annoncer la sortie d’Electron 30.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

Si vous avez des commentaires, veuillez les partager avec nous sur [Twitter] (https://twitter.com/electronjs) ou Mastodon, ou joignez-vous à notre communauté [Discord] (https://discord.com/invite/electronjs)! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables

  • ASAR Integrity fuse now supported on Windows (#40504)
    • Existing apps with ASAR Integrity enabled may not work on Windows if not configured correctly. Apps using Electron packaging tools should upgrade to @electron/packager@18.3.1 or @electron/forge@7.4.0.
    • Take a look at our ASAR Integrity tutorial for more information.
  • Added WebContentsView and BaseWindow main process modules, deprecating & replacing BrowserView (#35658). Learn more about how to migrate from BrowserView to WebContentsView in this blog post.
    • BrowserView is now a shim over WebContentsView and the old implementation has been removed.
    • See our Web Embeds documentation for a comparison of the new WebContentsView API to other similar APIs.
  • Implemented support for the File System API (#41827)

Le Google Summer of Code 2024

· 5 mins de lecture

Nous sommes heureux d'annoncer qu'Electron a été accepté en tant qu'organisation de mentorat pour la 20e édition du Google Summer of Code (GSoC) 2024 ! Le Google Summer of Code est un programme mondial visant à amener de nouveaux contributeurs à participer au développement de logiciels libres.

Pour plus de détails sur le programme, consultez la page d'accueil de Google Summer of Code.

À propos de nous

Electron est un framework JavaScript pour la construction d'applications de bureau multi-plateformes en utilisant les technologies web. Le framework cœur d'Electron est un exécutable binaire compilé avec Chromium et Node.js, et est principalement écrit en C++.

En dehors du cœur d'Electron, nous travaillons également sur une variété de projets pour aider à soutenir l'organisation Electron, comme :

En tant que contributeur du Summer of Code, vous seriez en train de collaborer avec certains des principaux contributeurs d'Electron sur l'un des nombreux projets sous github.com/electron parapluie.

Avant la demande

Si vous n'êtes pas très familier avec Electron, nous vous recommandons de commencer par lire la documentation et d'essayer des exemples dans Electron Fiddle.

Pour en savoir plus sur la distribution des applications Electron, vous pouvez également jouer avec Electron Forge en créant un exemple d'application :

npm init electron-app@latest my-app

Après vous être familiarisé un peu avec le code, venez rejoindre la conversation sur le serveur Discord Electron.

info

Si c'est la première fois que vous participez au Google Summer of Code ou si vous êtes novice en matière d'open source en général, nous vous recommandons de lire le Guide du contributeur de Google dans un premier temps avant de vous engager dans la communauté.

Ébauche de votre proposition

Êtes-vous intéressé à collaborer avec Electron? Premièrement, prenez le temps de regarder les sept idées de projets brouillons que nous avons préparé. Toutes les idées listées sont actuellement ouvertes aux propositions.

Vous avez une idée différente que vous aimeriez que nous prenions en considération ? Nous sommes également ouverts à l'acceptation de nouvelles idées que ne sont pas sur la liste de projet proposée, mais assurez-vous que votre approche est détaillée et détaillée. En cas de doute, nous vous recommandons de vous en tenir à nos idées énumérées.

Votre candidature devra inclure :

  • Votre proposition, avec un document écrit qui décrit en détail votre plan de ce que vous comptez achever au cours de cet été.
  • Votre expérience en tant que développeur. Si vous avez un curriculum vitae, veuillez en inclure une copie. Sinon, parlez nous de votre expérience technique passée.
    • Le manque d'expérience dans certains domaines ne vous disqualifiera pas, mais cela aidera nos mentors à élaborer un plan pour vous soutenir au mieux et s'assurer que votre projet d'été est couronné de succès.

Un guide détaillé de ce qu'il faut soumettre dans le cadre de votre demande Electron est ici. Soumettez des propositions directement sur le portail Google Summer of Code. Notez que les propositions envoyées à l'équipe Electron plutôt que soumises via le portail de candidature ne seront pas considérées comme une soumission finale.

Si vous voulez plus de conseils sur votre proposition ou si vous n'êtes pas certain de ce qu'il faut inclure, nous vous recommandons également de suivre le conseil officiel de Google Summer of Code en écrivant des propositions.

Les demandes sont ouvertes le 18 mars 2024 et fermées le 2 avril 2024.

info

Notre stagiaire Google Summer of Code 2022, @aryanshridhar, a fait un travail incroyable ! Si vous voulez savoir sur quoi Aryan a travaillé pendant son été avec Electron, , vous pouvez lire son rapport dans les archives du programme GSoC 2022.

Questions?

Si vous avez des questions que nous n'avons pas traitées dans le blog ou des demandes de renseignements pour votre projet de proposition, veuillez nous envoyer un email à summer-of-code@electronjs. rg ou vérifiez GSoC FAQ!

Ressources

Electron 29.0.0

· 5 mins de lecture

Electron 29.0.0 est disponible ! Comprend des mises à niveaux vers et Node.js.


L’équipe Electron est heureuse d’annoncer la sortie d’Electron 29.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

Si vous avez des commentaires, veuillez les partager avec nous sur [Twitter] (https://twitter.com/electronjs) ou Mastodon, ou joignez-vous à notre communauté [Discord] (https://discord.com/invite/electronjs)! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables

  • Added a new top-level webUtils module, a renderer process module that provides a utility layer to interact with Web API objects. The first available API in the module is webUtils.getPathForFile. Electron's previous File.path augmentation was a deviation from web standards; this new API is more in line with current web standards behavior.

Changements de la Stack

Electron 29 upgrades Chromium from 120.0.6099.56 to 122.0.6261.39, Node from 18.18.2 to 20.9.0, and V8 from 12.0 to 12.2.

Nouvelles fonctionnalités

  • Added new webUtils module, a utility layer to interact with Web API objects, to replace File.path augmentation. #38776
  • Added net module to utility process. #40890
  • Added a new Electron Fuse, grantFileProtocolExtraPrivileges, that opts the file:// protocol into more secure and restrictive behaviour that matches Chromium. #40372
  • Added an option in protocol.registerSchemesAsPrivileged to allow V8 code cache in custom schemes. #40544
  • Migrated app.{set|get}LoginItemSettings(settings) to use Apple's new recommended underlying framework on macOS 13.0+. #37244

Changements majeurs avec rupture de compatibilité

Comportement changement : ipcRenderer ne peut plus être envoyée vers contextBridge

Attempting to send the entire ipcRenderer module as an object over the contextBridge will now result in an empty object on the receiving side of the bridge. This change was made to remove / mitigate a security footgun. You should not directly expose ipcRenderer or its methods over the bridge. Instead, provide a safe wrapper like below:

contextBridge.exposeInMainWorld('app', {
onEvent: (cb) => ipcRenderer.on('foo', (e, ...args) => cb(args)),
});

Removed: renderer-process-crashed event on app

The renderer-process-crashed event on app has been removed. Use the new render-process-gone event instead.

// Removed
app.on('renderer-process-crashed', (event, webContents, killed) => {
/* ... */
});

// Replace with
app.on('render-process-gone', (event, webContents, details) => {
/* ... */
});

Removed: crashed event on WebContents and <webview>

The crashed events on WebContents and <webview> have been removed. Use the new render-process-gone event instead.

// Removed
win.webContents.on('crashed', (event, killed) => {
/* ... */
});
webview.addEventListener('crashed', (event) => {
/* ... */
});

// Replace with
win.webContents.on('render-process-gone', (event, details) => {
/* ... */
});
webview.addEventListener('render-process-gone', (event) => {
/* ... */
});

Removed: gpu-process-crashed event on app

The gpu-process-crashed event on app has been removed. Use the new child-process-gone event instead.

// Removed
app.on('gpu-process-crashed', (event, killed) => {
/* ... */
});

// Replace with
app.on('child-process-gone', (event, details) => {
/* ... */
});

Fin du support pour 26.x.y

Electron 26.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

E29 (Fev'24)E24 (Avr'24)E31 (Jun'24)
29.x.y30.x.y31.x.y
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y

Et maintenant ?

Did you know that Electron recently added a community Request for Comments (RFC) process? Si vous voulez ajouter une fonctionnalité à la structure, RFCs cela peut être un outil utile. Vous pouvez aussi voir les prochains changement en cours de discussion dans demande d'extraction. Pour en apprendre plus, vérifier notre [Introduction electron/rfc] (https://www.electronjs.org/blog/rfcs) article de blog, ou vérifier le README du [electron/rfcs] (https://www.github.com/electron/rfcs) dépôt directement.

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

More information about future changes can be found on the Planned Breaking Changes page.

Introducing electron/rfcs

· 4 mins de lecture

Electron’s API Working Group is adopting an open Requests for Comments (RFC) process to help shepherd larger changes to Electron core.

Why RFCs?

In short, we want to smooth out the process of landing significant changes to Electron core.

Currently, new code changes are mostly discussed through issues and pull requests on GitHub. For most changes to Electron, this is a good system. Many bug fixes, documentation changes, and even new features are straightforward enough to review and merge asynchronously through standard GitHub flows.

For changes that are more significant—for instance, large API surfaces or breaking changes that would affect the majority of Electron apps—it makes sense for review to happen at the ideation stage before most of the code is written.

This process is designed to be open to the public, which will also make it easier for the open source community at large to give feedback on potential changes before they land in Electron.

Comment ça marche ?

The entire RFC process lives in the electron/rfcs repository on GitHub. The steps are described in detail in the repository README.

In brief, an RFC is Proposed once a PR is made to the electron/rfcs repository. A Proposed RFC becomes:

  • Active when the PR is merged into the main branch of the repository, which means that Electron maintainers are amenable to an implementation in electron/electron, or
  • Declined if the PR is ultimately rejected.
info

For the RFC to become Active, the PR must be approved by at least 2 API Working Group members. Before merging, the RFC should be presented synchronously and accepted unanimously by a quorum of at least two-thirds of the WG members. If consensus is reached, a one-month final comment period will be triggered, after which the PR will be merged.

An Active RFC is Completed if the implementation has been merged into electron/electron.

Who can participate?

Anyone in the Electron community can submit RFCs or leave feedback on the electron/rfcs repository!

We wanted to make this process a two-way dialogue and encourage community participation to get a diverse set of opinions from Electron apps that might consume these APIs in the future. If you’re interested in leaving feedback on currently proposed RFCs, the Electron maintainers have already created a few:

Credits

Electron's RFC process was modeled on many established open source RFC processes. Inspiration for many ideas and major portions of copywriting go to:

Déclaration concernant les CVEs "runAsNode"

· 4 mins de lecture

Earlier today, the Electron team was alerted to several public CVEs recently filed against several notable Electron apps. The CVEs are related to two of Electron’s fuses - runAsNode and enableNodeCliInspectArguments - and incorrectly claim that a remote attacker is able to execute arbitrary code via these components if they have not been actively disabled.

We do not believe that these CVEs were filed in good faith. First of all, the statement is incorrect - the configuration does not enable remote code execution. Secondly, companies called out in these CVEs have not been notified despite having bug bounty programs. Lastly, while we do believe that disabling the components in question enhances app security, we do not believe that the CVEs have been filed with the correct severity. “Critical” is reserved for issues of the highest danger, which is certainly not the case here.

Anyone is able to request a CVE. While this is good for the overall health of the software industry, “farming CVEs” to bolster the reputation of a single security researcher is not helpful.

That said, we understand that the mere existence of a CVE with the scary critical severity might lead to end user confusion, so as a project, we’d like to offer guidance and assistance in dealing with the issue.

Comment cela pourrait-il avoir un impact pour moi?

After reviewing the CVEs, the Electron team believes that these CVEs are not critical.

An attacker needs to already be able to execute arbitrary commands on the machine, either by having physical access to the hardware or by having achieved full remote code execution. This bears repeating: The vulnerability described requires an attacker to already have access to the attacked system.

Chrome, for example, does not consider physically-local attacks in their threat model:

We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your device as you, or who can run software with the privileges of your operating system user account. Such an attacker can modify executables and DLLs, change environment variables like PATH, change configuration files, read any data your user account owns, email it to themselves, and so on. Such an attacker has total control over your device, and nothing Chrome can do would provide a serious guarantee of defense. This problem is not special to Chrome ­— all applications must trust the physically-local user.

The exploit described in the CVEs allows an attacker to then use the impacted app as a generic Node.js process with inherited TCC permissions. So if the app, for example, has been granted access to the address book, the attacker can run the app as Node.js and execute arbitrary code which will inherit that address book access. This is commonly known as a “living off the land” attack. Attackers usually use PowerShell, Bash, or similar tools to run arbitrary code.

Suis-je impacté?

Par défaut, toutes les versions publiées d'Electron ont les fonctionnalités runAsNode et enableNodeCliInspectArguments activées. If you have not turned them off as described in the Electron Fuses documentation, your app is equally vulnerable to being used as a “living off the land” attack. Again, we need to stress that an attacker needs to already be able to execute code and programs on the victim’s machine.

Atténuation

La façon la plus simple d'atténuer ce problème est de désactiver le fusible runAsNode dans votre application Electron. Le fuse runAsNode acitve ou désactive le respect de la variable d'environnement ELECTRON_RUN_AS_NODE. Please see the Electron Fuses documentation for information on how to toggle theses fuses.

Please note that if this fuse is disabled, then process.fork in the main process will not function as expected as it depends on this environment variable to function. Instead, we recommend that you use Utility Processes, which work for many use cases where you need a standalone Node.js process (like a Sqlite server process or similar scenarios).

Vous pouvez trouver plus d'informations sur les meilleures pratiques de sécurité que nous recommandons pour les applications Electron dans notre Liste de contrôle de sécurité.