Electron 35.0.0 вышел! It includes upgrades to Chromium 134.0.6998.44, V8 13.5, and Node 22.14.0.

Команда Electron рада объявить о выпуске Electron 35.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Service Worker Preload Scripts for Improved Extensions Support​

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'),
});

Furthermore, IPC is now available between Service Workers and their attached preload scripts via the ServiceWorkerMain.ipc class. 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.

Stack Changes​

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

New Features​

• 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

Критические изменения​

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

Окончание поддержки версии 32.x.y​

Electron 32.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

Что дальше​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and 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.

About us​

Electron is a JavaScript framework for building cross-platform desktop applications using web technologies. The core Electron framework is a compiled binary executable built with Chromium and Node.js, and is mostly written in 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.

Before applying​

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

After familiarizing yourself with the code a bit, come join the conversation on the Electron Discord server.

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​

Interested in collaborating with 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. When in doubt, we recommend sticking with our listed ideas.

Your application should include:

• A detailed proposal outlining what you plan to achieve over the summer.
• Your background as a developer. If you have a resume, please include a copy. 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.

Ресурсы​

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

Electron 34.0.0 вышел! It includes upgrades to Chromium 132.0.6834.83, V8 13.2, and Node 20.18.1.

Команда Electron рада объявить о выпуске Electron 34.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

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);
  });
});

Stack Changes​

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

New Features​

• 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
• Added error event in utility process to support diagnostic reports on V8 fatal errors. #43774
• Feat: GPU accelerated shared texture offscreen rendering. #42953

Критические изменения​

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.

Окончание поддержки версии 31.x.y​

Electron 31.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

Что дальше​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8.

You can find Electron's public timeline here.

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

In early 2025, Electron’s npm ecosystem repos (under the @electron/ and @electron-forge/ namespaces) will move to Node.js 22 as the minimum supported version.

What does this mean?​

In the past, packages in Electron’s npm ecosystem (Forge, Packager, etc) have supported Node versions for as long as possible, even after a version has reached its End-Of-Life (EOL) date. This is done to make sure we don’t fragment the ecosystem—we understand that many projects depend on older versions of Node, and we don’t want to risk stranding those projects unless there was a pressing reason to upgrade.

Over time, using Node.js 14 as our minimum version has become increasingly difficult for a few reasons:

• Lack of official Node.js 14 macOS ARM64 builds requires us to maintain CI infrastructure workarounds to provide full test coverage.
• 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).

Why upgrade now?​

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.

We’ve decided to set that update time to January/February 2025. After this upgrade occurs, Node 22 will be the minimum supported version in existing ecosystem packages.

What action do I need to take?​

We’ll strive to maintain compatibility as much as possible. However, to ensure the best support, we encourage you to upgrade your apps to Node 22 or higher.

Note that the Node version running in your project is unrelated to the Node version embedded into your current version of Electron.

What's next​

Please feel free to write to us at info@electronjs.org if you have any questions or concerns. You can also find community support in our official Electron Discord.

The Electron project will pause for the month of December 2024, then return to full speed in January 2025.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. 2024's last stable branch releases for the year, which include Electron 31, 32, and 33, will occur the week of December 1st. There will be no additional planned releases in December.
2. No Nightly and Alpha releases for the last two weeks of December.
3. With few exceptions, no pull request reviews or merges.
4. No issue tracker updates on any repositories.
5. No Discord debugging help from maintainers.
6. No social media content updates.

See you all in 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({
   
   информация

   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	Замечания
   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,
   +    });
   +  });
   
   подсказка

   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 вышел! It includes upgrades to Chromium 130.0.6723.44, V8 13.0, and Node 20.18.0.

Команда Electron рада объявить о выпуске Electron 33.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Highlights​

• Added a handler, app.setClientCertRequestPasswordHandler(handler), to help unlock cryptographic devices when a PIN is needed. #41205
• Extended navigationHistory API with 2 new functions for better history management. #42014
• Improved native theme transparency checking. #42862

Stack Changes​

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

New Features​

• Added a handler, app.setClientCertRequestPasswordHandler(handler), to help unlock cryptographic devices when a PIN is needed. #41205
• Added error event in utility process to support diagnostic reports on V8 fatal errors. #43997
• Added View.setBorderRadius(radius) for customizing the border radius of views—with compatibility for WebContentsView. #42320
• Extended navigationHistory API with 2 new functions for better history management. #42014

Критические изменения​

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. Developers using native node modules should build their modules with --std=c++20 rather than --std=c++17. Images using gcc9 or lower may need to update to gcc10 in order to compile. 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');

Behavior Changed: webContents property on login on 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;

End of Support for 30.x.y​

Electron 30.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

Что дальше​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8.

You can find Electron's public timeline here.

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

Historical changes to Electron APIs will now be detailed in the docs.

Hi 👋, I'm Peter, the 2024 Google Summer of Code (GSoC) contributor to Electron.

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 вышел! It includes upgrades to Chromium 128.0.6613.36, V8 12.8, and Node 20.16.0.

Команда Electron рада объявить о выпуске Electron 32.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Highlights​

• 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

Stack Changes​

• Chromium128.0.6613.36
  • New in 128
  • New in 127
• Node 20.16.0
  • Node 20.16.0 blog post
• V8 12.8

Electron 32 upgrades Chromium from 126.0.6478.36 to 128.0.6613.36, Node from 20.14.0 to 20.16.0, and V8 from 12.6 to 12.8.

New Features​

• Added support for responding to auth requests initiated from the utility process via the app module's 'login' event. #43317
• Added the cumulativeCPUUsage property to the CPUUsage structure, which returns the total seconds of CPU time used since process startup. #41819
• Added the following existing navigation related APIs to webContents.navigationHistory: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear. #41752
• Extended WebContentsView to accept pre-existing webContents objects. #42086
• Added a new property prefersReducedTransparency to nativeTheme, which indicates whether the user has chosen to reduce OS-level transparency via system accessibility settings. #43137
• Aligned failure pathway in File System Access API with upstream when attempting to open a file or directory in a blocked path. #42993
• Enabled the Windows Control Overlay API on Linux. #42681
• Enabled zstd compression in network requests. #43300

Критические изменения​

Removed: File.path​

The nonstandard path property of the Web File object was added in an early version of Electron as a convenience method for working with native files when doing everything in the renderer was more common. However, it represents a deviation from the standard and poses a minor security risk as well, so beginning in Electron 32.0 it has been removed in favor of the webUtils.getPathForFile method.

// Before (renderer)
const file = document.querySelector('input[type=file]');
alert(`Uploaded file path was: ${file.path}`);

// After (renderer)
const file = document.querySelector('input[type=file]');
electron.showFilePath(file);

// After (preload)
const { contextBridge, webUtils } = require('electron');

contextBridge.exposeInMainWorld('electron', {
  showFilePath(file) {
    // It's best not to expose the full file path to the web content if
    // possible.
    const path = webUtils.getPathForFile(file);
    alert(`Uploaded file path was: ${path}`);
  },
});

Deprecated: clearHistory, canGoBack, goBack, canGoForward, goForward, goToIndex, canGoToOffset, goToOffset on WebContents​

Navigation-related APIs on WebContents instances are now deprecated. These APIs have been moved to the navigationHistory property of WebContents to provide a more structured and intuitive interface for managing navigation history.

// Deprecated
win.webContents.clearHistory();
win.webContents.canGoBack();
win.webContents.goBack();
win.webContents.canGoForward();
win.webContents.goForward();
win.webContents.goToIndex(index);
win.webContents.canGoToOffset();
win.webContents.goToOffset(index);

// Replace with
win.webContents.navigationHistory.clear();
win.webContents.navigationHistory.canGoBack();
win.webContents.navigationHistory.goBack();
win.webContents.navigationHistory.canGoForward();
win.webContents.navigationHistory.goForward();
win.webContents.navigationHistory.canGoToOffset();
win.webContents.navigationHistory.goToOffset(index);

Behavior changed: Directory databases in userData will be deleted​

If you have a directory called databases in the directory returned by app.getPath('userData'), it will be deleted when Electron 32 is first run. The databases directory was used by WebSQL, which was removed in Electron 31. Chromium now performs a cleanup that deletes this directory. See issue #45396.

End of Support for 29.x.y​

Electron 29.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

Что дальше​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8.

You can find Electron's public timeline here.

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

Electron 31.0.0 вышел! It includes upgrades to Chromium 126.0.6478.36, V8 12.6, and Node 20.14.0.

Команда Electron рада объявить о выпуске Electron 31.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Highlights​

• 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

Stack Changes​

• Chromium126.0.6478.36
  • New in 126
  • New in 125
• Node 20.14.0
  • Node 20.14.0 blog post
• V8 12.6

Electron 31 upgrades Chromium from 124.0.6367.49 to 126.0.6478.36, Node from 20.11.1 to 20.14.0, and V8 from 12.4 to 12.6.

New Features​

• Added clearData method to Session. #40983
  • Added options parameter to Session.clearData API. #41355
• Added support for Bluetooth ports being requested by service class ID in navigator.serial. #41638
• Added support for Node's NODE_EXTRA_CA_CERTS environment variable. #41689
• Extended webContents.setWindowOpenHandler to support manual creation of BrowserWindow. #41432
• Implemented support for the web standard File System API. #41419
• Extended WebContentsView to accept pre-existing WebContents instances. #42319
• Added a new instance property navigationHistory on webContents API with navigationHistory.getEntryAtIndex method, enabling applications to retrieve the URL and title of any navigation entry within the browsing history. #41577 ^{(Also in 29, 30)}

Критические изменения​

Removed: WebSQL support​

Chromium has removed support for WebSQL upstream, transitioning it to Android only. See Chromium's intent to remove discussion for more information.

Behavior Changed: nativeImage.toDataURL will preseve PNG colorspace​

PNG decoder implementation has been changed to preserve colorspace data. The encoded data returned from this function now matches it.

See crbug.com/332584706 for more information.

Behavior Changed: win.flashFrame(bool) will flash dock icon continuously on macOS​

This brings the behavior to parity with Windows and Linux. Prior behavior: The first flashFrame(true) bounces the dock icon only once (using the NSInformationalRequest level) and flashFrame(false) does nothing. New behavior: Flash continuously until flashFrame(false) is called. This uses the NSCriticalRequest level instead. To explicitly use NSInformationalRequest to cause a single dock icon bounce, it is still possible to use dock.bounce('informational').

Окончание поддержки версии 28.x.y​

Electron 28.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

Что дальше​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8.

You can find Electron's public timeline here.

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