Electron 37.0.0 est disponible ! Il comprend des mises à jour vers Chromium 138, V8 13.8 et Node.js 22.16.0.

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 37.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.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! 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​

Coins arrondis: Squircles CSS natifs​

Electron 37 introduces the custom -electron-corner-smoothing CSS property, which allows apps to create smoother rounded corners to match Apple's macOS design language. This feature originally landed in Electron 36, but we felt like it deserved a brighter spotlight.

Exemple avec un lissage d'angle de 100%

Code	Result
.box { width: 128px; height: 128px; border-radius: 24px; -electron-corner-smoothing: 100%; }

Contrairement à la propriété standard border-radius, qui sculpte les coins du quart de cercle à partir d'un rectangle, -electron-corner-smoothing transforme en douceur la courbe vers une forme squircle avec un périmètre continu.

You can adjust the smoothness using values from 0% to 100%, or use the system-ui value to match the operating system's style (60% on macOS and 0% otherwise). This design enhancement can be applied on borders, outlines, and shadows, giving your app a subtle layer of polish.

Changements de la Stack​

• Chromium 138.0.7204.35
  • Nouveau en 138
  • Nouveau en 137
• Node 22.16.0
  • Notes Node 22.16.0
• V8 13.8

Electron 37 met à jour Chromium de 136.0.7103.48 à 138.0.7204.35 et V8 de 13.6 à 13.8.

Google Summer of Code Begins​

Our two Google Summer of Code contributors have started the program's coding period!

• @nilayarya is crafting a new Save/Restore Window State API in Electron core. The new APIs will provide a built-in, standardized way to handle window state persistence. See Nilay's in-progress RFC at electron/rfcs#16.
• @hitarth-gg is hard at work modernizing the long-dormant Devtron extension using Chrome Manifest V3 APIs. This project will provide tooling for developers to debug IPC communication, track event listeners, and visualize module dependencies in their Electron applications.

It has been an exciting couple of weeks for our GSOC participants, so stay tuned for more updates!

Nouvelles fonctionnalités et améliorations​

• Added innerWidth and innerHeight options for window.open. #47039 (Également en 35, 36)
• Added before-mouse-event to allow intercepting and preventing mouse events in webContents. #47364 (Également en 36)
• Added scriptURL property to ServiceWorkerMain. #45863
• Added sublabel functionality for menus on macOS >= 14.4. #47042 (Également en 35, 36)
• Added support for HIDDevice.collections. #47483 (Également en 36)
• Added support for --no-experimental-global-navigator flag. #47418 (Également en 35, 36)
• Added support for screen.dipToScreenPoint(point) and screen.screenToDipPoint(point) on Linux X11. #46895 (Également en 35, 36)
• Added support for menu item role palette and header on macOS. #47245
• Added support for node option --experimental-network-inspection. #47031 (Également en 35, 36)
• Exposed win.isContentProtected() to allow developers to check window protection status. #47310 (Également en 36)

Changements majeurs avec rupture de compatibilité​

Utility Process unhandled rejection behavior change​

Utility Processes will now warn with an error message when an unhandled rejection occurs instead of crashing the process.

To restore the previous behavior, you can use:

process.on('unhandledRejection', () => {
  process.exit(1);
});

Comportement modifié : process.exit() termine l'utilitaire de façon synchronisée​

Calling process.exit() in a utility process will now kill the utility process synchronously. This brings the behavior of process.exit() in line with Node.js behavior.

Please refer to the Node.js docs and PR #45690 to understand the potential implications of that, e.g., when calling console.log() before process.exit().

Behavior Changed: WebUSB and WebSerial Blocklist Support​

WebUSB and Web Serial now support the WebUSB Blocklist and Web Serial Blocklist used by Chromium and outlined in their respective specifications.

To disable these, users can pass disable-usb-blocklist and disable-serial-blocklist as command line flags.

Supprimé: valeur null pour la propriété session dans ProtocolResponse​

This deprecated feature has been removed.

Previously, setting the ProtocolResponse.session property to null would create a random independent session. This is no longer supported.

Using single-purpose sessions here is discouraged due to overhead costs; however, old code that needs to preserve this behavior can emulate it by creating a random session with session.fromPartition(some_random_string) and then using it in ProtocolResponse.session.

Comportement modifié : BrowserWindow.IsVisibleOnAllWorkspaces() sur Linux​

BrowserWindow.IsVisibleOnAllWorkspaces() will now return false on Linux if the window is not currently visible.

Fin du support pour 34.x.y​

Electron 34.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.

Et maintenant ?​

À 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.

Electron 36.0.0 est disponible ! Il comprend des mises à jour vers Chromium 136, V8 13.6 et Node.js 22.14.0.

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 36.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.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! 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​

Support des outils d'écriture​

Dans Electron 36, vous pouvez activer les fonctionnalités du système macOS telles que les outils d'écriture (orthographe et grammaire), le remplissage automatique et les éléments de menu Services dans vos menus contextuels. Pour ce faire, passez une instance WebFrameMain dans le paramètre frame de menu.popup().

import { BrowserWindow, Menu, WebFrameMain } from 'electron';

const currentWindow = BrowserWindow.getFocusedWindow();
const focusedFrame = currentWindow.webContents.focusedFrame;
const menu = Menu.buildFromTemplate([{ label: 'Copy', role: 'copy' }]);

menu.popup({
  window: currentWindow,
  frame: focusedFrame,
});

Changements de la Stack​

• Chromium 136.0.7103.48
  • Nouveau en 136
  • [https://developer.chrome.com/blog/new-in-chrome-135)
• Node 22.14.0
  • Node 22.14.0 blog post
• V8 13.6

Electron 36 met à jour Chromium de 134.0.6998.23 à 136.0.7103.48 et V8 de 13.5 à 13.6.

Nouvelles fonctionnalités et améliorations​

• Ajout de "BrowserWindow.isSnapped()" pour indiquer si une fenêtre donnée a été disposée par Snap sur Windows. #46226
• Ajout de WebContents.focusedFrame pour obtenir la frame ciblée.
• Correction de WebContents.opener pour spécifier le type potentiel null. #45667
• Ajout de ffmpeg.dll pour retarder la configuration de chargement. #46173 (Également en 34, 35)
• Ajout de nativeTheme.shouldUseDarkColorsForSystemIntegratedUI pour distinguer le thème du système et de l'application. #46598 (Également en 35)
• Ajout de excludeUrls au filtre webRequest et dépréciation de l'utilisation de tableaux vides dans la propriété urls. #44692 (Également en 35)
• Added support for Autofill, Writing Tools and Services macOS level menu items in context menus via the new frame option in menu.popup. #46350
• Added support for system-context-menu on Linux. #46399
• Improved ASAR integrity checks on Windows. #46537
• Improved performance of desktopCapturer.getSources when not requesting thumbnails on macOS. #46251 (Also in 34, 35)
• Removed 240 FPS limit when using shared texture OSR. #45669 (Also in 35)

Changements majeurs avec rupture de compatibilité​

Obsolète : NativeImage.getBitmap()​

The NativeImage.getBitmap() function is now deprecated and documented as an alias for NativeImage.toBitmap(). The two functions both return a newly-allocated copy of the bitmap and are functionally equivalent.

Obsolète: Méthodes d'extension et événements sur session​

session.loadExtension’, ‘session.removeExtension’, ‘session.getExtension’, ‘session.getAllExtensions’, et les événements extension-loaded’, extension-déchargée’, et extension-ready’' ont tous déménagé dans le nouveau Extensions object accessible par l’intermédiaire de la propriété d'instance session.extensions.

Supprimé: quota type syncable dans session.clearStorageData(options)​

When calling session.clearStorageData(options), the options.quota type syncable is no longer supported because it has been removed from upstream Chromium.

Deprecated: quota property in session.clearStorageData(options)​

When calling Session.clearStorageData(options), the options.quota property is deprecated. Since the syncable type was removed, there is only type left -- 'temporary' -- so specifying it is unnecessary.

Comportement modifié : GTK 4 est la valeur par défaut lors de l'exécution sur GNOME​

After an upstream change, GTK 4 is now the default when running on GNOME.

In rare cases, this may cause some applications or configurations to error with the following message:

Gtk-ERROR **: 11:30:38.382: GTK 2/3 symbols detected. Using GTK 2/3 and GTK 4 in the same process is not supported

Affected users can work around this by specifying the gtk-version command-line flag:

$ electron --gtk-version=3   # or --gtk-version=2

The same can be done with the app.commandLine.appendSwitch function.

Changements de comportement : app.commandLine​

app.commandLine will convert uppercases switches and arguments to lowercase.

app.commandLine was only meant to handle Chromium switches (which aren't case-sensitive) and switches passed via app.commandLine will not be passed down to any of the child processes.

If you were using app.commandLine to parse app-specific command line arguments, you should do this via process.argv.

Fin du support pour 33.x.y​

Electron 33.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.

Et maintenant ?​

À 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.

Electron 35.0.0 est disponible ! Il inclut des mises à jour vers Chromium 134.0.6998.44, V8 13.5, et Node.js `22.14.0.

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 35.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.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! 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​

Scripts de Service Worker Preload pour une prise en charge améliorée des extensions​

Originally proposed in RFC #8 by @samuelmaddock, Electron 35 adds the ability to attach a preload script to Service Workers. With Chrome's Manifest V3 Extensions routing a lot of work through extension service workers, this feature fills in a gap in Electron's support for modern Chrome extensions.

When registering a preload script programmatically at the Session level, you can now specifically apply it to Service Worker contexts with the ses.registerPreloadScript(script) API.

// Add our preload realm script to the session.
session.defaultSession.registerPreloadScript({
  // Our script should only run in service worker preload realms.
  type: 'service-worker',
  // The absolute path to the script.
  script: path.join(__dirname, 'extension-sw-preload.js'),
});

De plus, l'IPC est maintenant disponible entre les Service Workers et leurs scripts de préchargement via la classe ServiceWorkerMain.ipc. The preload script will still use the ipcRenderer module to communicate with its Service Worker. See the original RFC for more details.

This feature was preceded by many other changes that laid the groundwork for it:

• #45329 redesigned the Session module's preload APIs to support registering and unregistering individual preload scripts.
• #45229 added the experimental contextBridge.executeInMainWorld(executionScript) script to evaluate JavaScript in the main world over the context bridge.
• #45341 added the ServiceWorkerMain class to interact with Service Workers in the main process.

Changements de la Stack​

• Chromium 134.0.6998.44
  • New in 134
  • New in 133
• Node 22.14.0
  • Node 22.14.0 blog post
• V8 13.5

Electron 35 upgrades Chromium from 132.0.6834.83 to 134.0.6998.44, Node from 20.18.1 to 22.14.0, and V8 from 13.2 to 13.5.

Nouvelles fonctionnalités​

• Added NSPrefersDisplaySafeAreaCompatibilityMode = false to Info.plist to remove "Scale to fit below built-in camera." from app options. #45357 ^{(Also in v34.1.0)}
• Added ServiceWorkerMain class to interact with service workers in the main process. #45341
  • Added running-status-changed event on ServiceWorkers to indicate when a service worker's running status has changed.
  • Added startWorkerForScope on ServiceWorkers to start a worker that may have been previously stopped.
• Added experimental contextBridge.executeInMainWorld to safely execute code across world boundaries. #45330
• Added frame to 'console-message' event. #43617
• Added query-session-end event and improved session-end events on Windows. #44598
• Added view.getVisible(). #45409
• Added webContents.navigationHistory.restore(index, entries) API that allows restoration of navigation history. #45583
• Added optional animation parameter to BrowserWindow.setVibrancy. #35987
• Added permission support for document.executeCommand("paste"). #45471 ^{(Also in v34.1.0)}
• Added support for roundedCorners BrowserWindow constructor option on Windows. #45740 ^{(Also in v34.3.0)}
• Added support for service worker preload scripts. #45408
• Support Portal's globalShortcuts. Electron must be run with --enable-features=GlobalShortcutsPortal in order to have the feature working. #45297

Changements majeurs avec rupture de compatibilité​

Removed: isDefault and status properties on PrinterInfo​

These properties have been removed from the PrinterInfo object because they have been removed from upstream Chromium.

Deprecated: getFromVersionID on session.serviceWorkers​

The session.serviceWorkers.fromVersionID(versionId) API has been deprecated in favor of session.serviceWorkers.getInfoFromVersionID(versionId). This was changed to make it more clear which object is returned with the introduction of the session.serviceWorkers.getWorkerFromVersionID(versionId) API.

// Deprecated
session.serviceWorkers.fromVersionID(versionId);

// Replace with
session.serviceWorkers.getInfoFromVersionID(versionId);

Deprecated: setPreloads, getPreloads on Session​

registerPreloadScript, unregisterPreloadScript, and getPreloadScripts are introduced as a replacement for the deprecated methods. These new APIs allow third-party libraries to register preload scripts without replacing existing scripts. Also, the new type option allows for additional preload targets beyond frame.

// Deprecated
session.setPreloads([path.join(__dirname, 'preload.js')]);

// Replace with:
session.registerPreloadScript({
  type: 'frame',
  id: 'app-preload',
  filePath: path.join(__dirname, 'preload.js'),
});

Deprecated: level, message, line, and sourceId arguments in console-message event on WebContents​

The console-message event on WebContents has been updated to provide details on the Event argument.

// Deprecated
webContents.on(
  'console-message',
  (event, level, message, line, sourceId) => {},
);

// Replace with:
webContents.on(
  'console-message',
  ({ level, message, lineNumber, sourceId, frame }) => {},
);

Additionally, level is now a string with possible values of info, warning, error, and debug.

Behavior Changed: urls property of WebRequestFilter.​

Previously, an empty urls array was interpreted as including all URLs. To explicitly include all URLs, developers should now use the <all_urls> pattern, which is a designated URL pattern that matches every possible URL. This change clarifies the intent and ensures more predictable behavior.

// Deprecated
const deprecatedFilter = {
  urls: [],
};

// Replace with
const newFilter = {
  urls: ['<all_urls>'],
};

Deprecated: systemPreferences.isAeroGlassEnabled()​

The systemPreferences.isAeroGlassEnabled() function has been deprecated without replacement. It has been always returning true since Electron 23, which only supports Windows 10+, where DWM composition can no longer be disabled.

https://learn.microsoft.com/en-us/windows/win32/dwm/composition-ovw#disabling-dwm-composition-windows7-and-earlier

Fin du support pour 32.x.y​

Electron 32.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.

Et maintenant ?​

À 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.

Electron has once again been accepted as a mentoring organization for Google Summer of Code (GSoC) 2025! Google Summer of Code is a global program focused on bringing new contributors into open source software development.

For more details about the program, visit Google’s Summer of Code homepage.

À 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++.

Outside of the Electron core repository, we also maintain several projects to support the Electron ecosystem, including:

• Tools for end-user distribution (e.g. Electron Forge and update.electronjs.org).
• Learning materials for Electron developers (e.g. electronjs.org and Electron Fiddle).
• Internal tools to enhance developer productivity (e.g. Electron Build Tools and Sheriff).

As a GSoC contributor, you will have the opportunity to collaborate with some of Electron’s core contributors on one of many projects under the github.com/electron umbrella.

Avant la demande​

If you aren’t very familiar with Electron, we would recommend you start by reading the documentation and trying out some of the examples in Electron Fiddle.

To learn more about distributing Electron apps, try creating a sample application with Electron Forge:

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.

Project contributions​

We encourage you to take a look at any repositories that are relevant to the project ideas you are interested in. One way of doing your research is to make contributions by reporting bugs, triaging existing issues, or submitting pull requests. Doing so is an effective way of getting hands-on practice with our codebases, but is not mandatory for proposal submissions. A well-crafted proposal should be able to demonstrate your understanding of the code without needing to refer to past contributions.

Here are a few tips if you are looking to contribute to Electron before submitting your proposal:

1. Please provide descriptive issue or PR descriptions when submitting contributions. Regardless of the code itself, putting effort into the written part of a contribution shows us that you can be an effective communicator in a collaborative environment.
2. PRs are always welcome for open issues. You do not need to comment on an issue asking a maintainer if you can be assigned to it. Note that we still encourage you to discuss potential solutions on an issue if you need to refine an idea for a solution, but comments strictly asking if you can work on something are redundant and add noise to the issue tracker.
3. Low-effort project contributions (e.g. invalid issue reports, trivial wording changes in a repo README, or minor stylistic changes to front-end code) will negatively impact your final proposal, as they take up limited maintainer time and do not provide any net benefit to the Electron project.
4. While AI coding assistants can be an effective tool for debugging and understanding new concepts, we highly discourage contributions that are copy/pasted directly from AI-generated output. These often turn out to be of low quality, and it's often more effort for maintainers to clean up code generated from an LLM than for us to just reject a PR altogether.

Crafting your proposal​

Êtes-vous intéressé à collaborer avec Electron? First, check out the seven project idea drafts we have prepared. All listed ideas are open for proposals.

If you have a unique idea not on the list, we are open to considering it, but ensure your proposal is detailed and thoroughly outlined. En cas de doute, nous vous recommandons de vous en tenir à nos idées énumérées.

Votre candidature devra inclure :

• A detailed proposal outlining what you plan to achieve over the summer.
• Votre expérience en tant que développeur. Si vous avez un curriculum vitae, veuillez en inclure une copie. Otherwise, tell us about your past technical experience.
  • Lack of experience in certain areas won’t disqualify you, but it will help our mentors work out a plan to best support you and make sure your summer project is successful.

A detailed guide of what to submit as part of your Electron application is here. Submit proposals directly to the Google Summer of Code portal. Proposals emailed to the Electron team will not be considered as final submissions.

For more guidance on your proposal, we recommend you follow the official Google Summer of Code proposal writing advice here.

Applications open on March 24th, 2025 and close on April 8th, 2025.

Questions?​

If you have questions we didn’t address in this blog post or inquiries about your proposal draft, please send us an email at summer-of-code@electronjs.org or check the GSoC FAQ. Please read our contributor guidance before emailing.

Ressources​

• Electron Google Summer of Code 2025 Ideas List
• Electron Google Summer of Code 2025 Contributor Guidance
• Google Summer of Code Student/Contributeur Guide

Electron 34.0.0 est disponible ! It includes upgrades to Chromium 132.0.6834.83, V8 13.2, and Node 20.18.1.

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 34.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.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! 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​

HTTP Compression Shared Dictionary Management APIs​

HTTP compression allows data to be compressed by a web server before being received by the browser. Modern versions of Chromium support Brotli and Zstandard, which are newer compression algorithms that perform better for text files than older schemes such as gzip.

Custom shared dictionaries further improve the efficiency of Brotli and Zstandard compression. See the Chrome for Developers blog on shared dictionaries for more information.

@felixrieseberg added the following APIs in #44950 to manage shared dictionaries at the Session level:

• session.getSharedDictionaryUsageInfo()
• session.getSharedDictionaryInfo(options)
• session.clearSharedDictionaryCache()
• session.clearSharedDictionaryCacheForIsolationKey(options)

Unresponsive Renderer JavaScript Call Stacks​

Electron's unresponsive event occurs whenever a renderer process hangs for an excessive period of time. The new WebFrameMain.collectJavaScriptCallStack() API added by @samuelmaddock in #44204 allows you to collect the JavaScript call stack from the associated WebFrameMain object (webContnets.mainFrame).

This API can be useful to determine why the frame is unresponsive in cases where there's long-running JavaScript events causing the process to hang. For more information, see the proposed web standard Crash Reporting API.

const { app } = require('electron');

app.commandLine.appendSwitch(
  'enable-features',
  'DocumentPolicyIncludeJSCallStacksInCrashReports',
);

app.on('web-contents-created', (_, webContents) => {
  webContents.on('unresponsive', async () => {
    // Interrupt execution and collect call stack from unresponsive renderer
    const callStack = await webContents.mainFrame.collectJavaScriptCallStack();
    console.log('Renderer unresponsive\n', callStack);
  });
});

Changements de la Stack​

• Chromium 132.0.6834.83
  • New in 131
  • New in 132
• Node 20.18.1
  • Node 20.18.1 blog post
• V8 13.2

Electron 34 upgrades Chromium from 130.0.6723.44 to 132.0.6834.83, Node from 20.18.0 to 20.18.1, and V8 from 13.0 to 13.2.

Nouvelles fonctionnalités​

• Added APIs to manage shared dictionaries for compression efficiency using Brotli or ZStandard. The new APIs are session.getSharedDictionaryUsageInfo(), session.getSharedDictionaryInfo(options), session.clearSharedDictionaryCache(), and session.clearSharedDictionaryCacheForIsolationKey(options). #44950
• Added WebFrameMain.collectJavaScriptCallStack() for accessing the JavaScript call stack of unresponsive renderers. #44938
• Added WebFrameMain.detached for frames in an unloading state.
  • Added WebFrameMain.isDestroyed() to determine if a frame has been destroyed.
  • Fixed webFrameMain.fromId(processId, frameId) returning a WebFrameMain instance which doesn't match the given parameters when the frame is unloading. #43473
• Ajout d'un événement d'erreur dans le processus utilitaire pour supporter les rapports de diagnostic sur les erreurs fatales V8. #43774
• Feat: GPU accelerated shared texture offscreen rendering. #42953

Changements majeurs avec rupture de compatibilité​

Behavior Changed: menu bar will be hidden during fullscreen on Windows​

This brings the behavior to parity with Linux. Prior behavior: Menu bar is still visible during fullscreen on Windows. New behavior: Menu bar is hidden during fullscreen on Windows.

Correction: This was previously listed as a breaking change in Electron 33, but was first released in Electron 34.

Fin du support pour 31.x.y​

Electron 31.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.

Et maintenant ?​

À 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.

Au début de l'année 2025, le repos de l'écosystème npm d'Electron (sous les espaces de noms @electron/ et @electron-forge/) passera à Node.js 22 pour la version minimale supportée.

Qu’est-ce que ça signifie ?​

Dans le passé, les paquets dans l'écosystème npm d'Electron (Forge, Packager, etc) ont pris en charge les versions de Node aussi longtemps que possible, même une fois qu'une version a atteint sa date de fin de vie (EOL) . Ceci pour s'assurer que nous ne fragmentons pas l'écosystème - nous comprenons bien que de nombreux projets dépendent des anciennes versions de Node, et nous ne voulons pas risquer de bloquer ces projets à moins qu’il y ait une raison pressante de les améliorer.

Avec le temps, l'utilisation de Node.js 14 comme notre version minimale est devenue de plus en plus difficile pour quelques raisons :

• Le manque de versions officielles de Node.js 14 pour macOS ARM64 nous oblige à maintenir des solutions d'infrastructure de CI pour fournir une couverture de test complète.
• engines requirements for upstream package dependencies have moved forward, making it increasingly difficult to resolve supply chain security issues with dependency bumps.

Additionally, newer versions of Node.js have included many improvements that we would like to leverage, such as runtime-native common utilities (e.g. fs.glob and util.parseArgs) and entire new batteries-included modules (e.g. node:test, node:sqlite).

Pourquoi mettre à niveau maintenant ?​

In July 2024, Electron’s Ecosystem Working Group decided to upgrade all packages to the earliest Node version where require()of synchronous ESM graphs will be supported (see nodejs/node#51977 and nodejs/node#53500) at a future point after that version reaches its LTS date.

Nous avons décidé d'effectuer cette de mise à jour en Janvier/Février 2025. Après cette mise à jour, Node 22 sera la version minimale supportée dans les paquets écosystèmes existants.

Quelles mesures devrais-je prendre ?​

Nous nous efforcerons de maintenir la compatibilité autant que possible. Cependant, pour assurer le meilleur support possible, nous vous encourageons à mettre à jour vos applications vers Node 22 ou plus.

Notez que la version de Node exécutée dans votre projet n'est pas liée à la version de Node embarquée dans votre version actuelle d'Electron.

Et pour la suite​

N'hésitez pas à nous joindre sur info@electronjs.org](mailto:info@electronjs.org si vous avez des questions ou des préoccupations. Vous pouvez également obtenir le support de la communauté sur notre Discord Electron.

Le projet Electron fera une pause pour le mois de décembre 2024 et reviendra gonflé à bloc en janvier 2025.

via GIPHY

Ce qui ne changera pas en Décembre​

1. Les versions zero-day et autres versions majeures liées à la sécurité seront publiées si nécessaire. Les incidents de sécurité doivent être signalés via SECURITY.md.
2. Les rapports du Code de conduite et la modération se poursuivront normalement.

Ce qui sera différent en Décembre​

1. Les dernières versions de la branche stable de l'année 2024, dont Electron 31, 32 et 33, auront lieu la semaine du 1er décembre. Il n'y aura pas de nouvelles sorties prévues en décembre.
2. Pas de sorties Nightly et Alpha pour les deux dernières semaines de décembre.
3. À quelques exceptions près, il n'y aura pas de ré-éxamen de pull request ni de merge.
4. Aucune mise à jour de suivi de tickets sur aucun dépôt.
5. Aucune aide de débogage de la part des mainteneurs sur Discord.
6. Aucune mise à jour du contenu des réseaux sociaux.

On se revoit en 2025!

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​

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.

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 Method	New Method	Remarques
   win.setBrowserView	win.contentView.removeChildView + win.contentView.addChildView
   win.getBrowserView	win.contentView.children
   win.removeBrowserView	win.contentView.removeChildView
   win.setTopBrowserView	win.contentView.addChildView	Calling addChildView on an existing view reorders it to the top.
   win.getBrowserViews	win.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 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​

Points clés​

• 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

Changements de la Stack​

• Chromium 130.0.6723.44
  • New in 130
  • New in 129
• Node 20.18.0
  • Node 20.18.0 blog post
  • Node 20.17.0 blog post
• V8 13.0

Electron 33 upgrades Chromium from 128.0.6613.36 to 130.0.6723.44, Node from 20.16.0 to 20.18.0, and V8 from 12.8 to 13.0.

Nouvelles fonctionnalités​

• 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
• Ajout d'un événement d'erreur dans le processus utilitaire pour supporter les rapports de diagnostic sur les erreurs fatales V8. #43997
• Ajout de View.setBorderRadius(radius) pour personnaliser le rayon de bordure des vues, pour être compatible avec WebContentsView. #42320
• Extended navigationHistory API with 2 new functions for better history management. #42014

Changements majeurs avec rupture de compatibilité​

Removed: macOS 10.15 support​

macOS 10.15 (Catalina) is no longer supported by Chromium.

Older versions of Electron will continue to run on Catalina, but macOS 11 (Big Sur) or later will be required to run Electron v33.0.0 and higher.

Behavior Changed: Native modules now require C++20​

Due to changes made upstream, both V8 and Node.js now require C++20 as a minimum version. Les développeurs qui utilisent des modules natifs de node devraient compiler leurs modules avec --std=c++20 plutôt que --std=c++17. Les images utilisant gcc9 ou inférieur peuvent avoir besoin de se mettre à jour vers gcc10 pour compiler. See #43555 for more details.

Behavior Changed: custom protocol URL handling on Windows​

Due to changes made in Chromium to support Non-Special Scheme URLs, custom protocol URLs that use Windows file paths will no longer work correctly with the deprecated protocol.registerFileProtocol and the baseURLForDataURL property on BrowserWindow.loadURL, WebContents.loadURL, and <webview>.loadURL. protocol.handle will also not work with these types of URLs but this is not a change since it has always worked that way.

// No longer works
protocol.registerFileProtocol('other', () => {
  callback({ filePath: '/path/to/my/file' });
});

const mainWindow = new BrowserWindow();
mainWindow.loadURL(
  'data:text/html,<script src="loaded-from-dataurl.js"></script>',
  { baseURLForDataURL: 'other://C:\\myapp' },
);
mainWindow.loadURL('other://C:\\myapp\\index.html');

// Replace with
const path = require('node:path');
const nodeUrl = require('node:url');
protocol.handle(other, (req) => {
  const srcPath = 'C:\\myapp\\';
  const reqURL = new URL(req.url);
  return net.fetch(
    nodeUrl.pathToFileURL(path.join(srcPath, reqURL.pathname)).toString(),
  );
});

mainWindow.loadURL(
  'data:text/html,<script src="loaded-from-dataurl.js"></script>',
  { baseURLForDataURL: 'other://' },
);
mainWindow.loadURL('other://index.html');

Comportement modifié : propriété webContents sur login sur app​

The webContents property in the login event from app will be null when the event is triggered for requests from the utility process created with respondToAuthRequestsFromMainProcess option.

Deprecated: textured option in BrowserWindowConstructorOption.type​

The textured option of type in BrowserWindowConstructorOptions has been deprecated with no replacement. This option relied on the NSWindowStyleMaskTexturedBackground style mask on macOS, which has been deprecated with no alternative.

Deprecated: systemPreferences.accessibilityDisplayShouldReduceTransparency​

The systemPreferences.accessibilityDisplayShouldReduceTransparency property is now deprecated in favor of the new nativeTheme.prefersReducedTransparency, which provides identical information and works cross-platform.

// Deprecated
const shouldReduceTransparency =
  systemPreferences.accessibilityDisplayShouldReduceTransparency;

// Replace with:
const prefersReducedTransparency = nativeTheme.prefersReducedTransparency;

Fin du support pour 30.x.y​

Electron 30.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.

Et maintenant ?​

À 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.

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.