Das Electron-Projekt wird für den Monat Dezember 2024 pausieren und dann im Januar 2025 in voller Geschwindigkeit zurückkehren.

via GIPHY

Was im Dezember gleich sein wird​

1. Bei Bedarf werden Tages- und andere wichtige sicherheitsrelevante Veröffentlichungen veröffentlicht. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

Was wird im Dezember anders sein​

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. Mit wenigen Ausnahmen, keine Pull-Request Reviews oder Merges.
4. Keine Updates für Issue-Tracker auf Repositories.
5. Keine Discord Debugging-Hilfe von Betreuern.
6. Keine Updates für Inhalte der sozialen Medien.

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({
   
   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	Hinweise:
   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,
   +    });
   +  });
   
   tipp

   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 wurde veröffentlicht! It includes upgrades to Chromium 130.0.6723.44, V8 13.0, and Node 20.18.0.

Das Electron-Team freut sich, die Veröffentlichung von Electron 33.0.0 ankündigen zu können! Sie können es mit npm über npm electron@latest installieren oder von unserer Releases-Website herunterladen. Lesen Sie weiter für Details zu dieser Version.

Wenn Sie Feedback haben, teilen Sie es uns bitte auf Twitter oder Mastodon mit oder treten Sie unserem Community-Discord bei! Bugs und Feature-Anfragen können im Issue-Tracker von Electron gemeldet werden.

Bemerkenswerte Änderungen​

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-Änderungen​

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

Neue Funktionen​

• 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

Breaking Changes​

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

What's Next​

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.

Sie können die öffentliche Zeitleiste von Electron hier finden.

Weitere Informationen über zukünftige Änderungen können auf der Geplante Breaking Changes Seite gefunden werden.

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 wurde veröffentlicht! It includes upgrades to Chromium 128.0.6613.36, V8 12.8, and Node 20.16.0.

Das Electron-Team freut sich, die Veröffentlichung von Electron 32.0.0 ankündigen zu können! Sie können es mit npm über npm electron@latest installieren oder von unserer Releases-Website herunterladen. Lesen Sie weiter für Details zu dieser Version.

Wenn Sie Feedback haben, teilen Sie es uns bitte auf Twitter oder Mastodon mit oder treten Sie unserem Community-Discord bei! Bugs und Feature-Anfragen können im Issue-Tracker von Electron gemeldet werden.

Bemerkenswerte Änderungen​

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-Änderungen​

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

Neue Funktionen​

• 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

Breaking Changes​

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

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.

What's Next​

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.

Sie können die öffentliche Zeitleiste von Electron hier finden.

Weitere Informationen über zukünftige Änderungen können auf der Geplante Breaking Changes Seite gefunden werden.

Electron 31.0.0 wurde veröffentlicht! It includes upgrades to Chromium 126.0.6478.36, V8 12.6, and Node 20.14.0.

Das Electron-Team freut sich, die Veröffentlichung von Electron 31.0.0 ankündigen zu können! Sie können es mit npm über npm electron@latest installieren oder von unserer Releases-Website herunterladen. Lesen Sie weiter für Details zu dieser Version.

Wenn Sie Feedback haben, teilen Sie es uns bitte auf Twitter oder Mastodon mit oder treten Sie unserem Community-Discord bei! Bugs und Feature-Anfragen können im Issue-Tracker von Electron gemeldet werden.

Bemerkenswerte Änderungen​

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-Änderungen​

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

Neue Funktionen​

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

Breaking Changes​

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').

Ende der Unterstützung für 28.x.y​

Electron 28.x.y hat das Ende des Supports gemäß der Support-Richtlinie des Projekts erreicht. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

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.

Sie können die öffentliche Zeitleiste von Electron hier finden.

Weitere Informationen über zukünftige Änderungen können auf der Geplante Breaking Changes Seite gefunden werden.

Electron 30.0.0 wurde veröffentlicht! It includes upgrades to Chromium 124.0.6367.49, V8 12.4, and Node.js 20.11.1.

Das Electron-Team freut sich, die Veröffentlichung von Electron 30.0.0 ankündigen zu können! Sie können es mit npm über npm electron@latest installieren oder von unserer Releases-Website herunterladen. Lesen Sie weiter für Details zu dieser Version.

Wenn Sie Feedback haben, teilen Sie es uns bitte auf Twitter oder Mastodon mit oder treten Sie unserem Community-Discord bei! Bugs und Feature-Anfragen können im Issue-Tracker von Electron gemeldet werden.

Bemerkenswerte Änderungen​

Highlights​

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

Stack-Änderungen​

• Chromium 124.0.6367.49
  • Neu in Chrome 124 und in DevTools 124
  • Neu in Chrome 123 und in DevTools 123
• Node 20.11.1
  • Anmerkungen zu Node 20.11.1
• V8 12.4

Electron 30 upgrades Chromium from 122.0.6261.39 to 124.0.6367.49, Node from 20.9.0 to 20.11.1, and V8 from 12.2 to 12.4.

Neue Funktionen​

• Added a transparent webpreference to webviews. (#40301)
• 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. (#41662)
• Added new BrowserWindow.isOccluded() method to allow apps to check occlusion status. (#38982)
• Added proxy configuring support for requests made with the net module from the utility process. (#41417)
• Added support for Bluetooth ports being requested by service class ID in navigator.serial. (#41734)
• Added support for the Node.js NODE_EXTRA_CA_CERTS CLI flag. (#41822)

Breaking Changes​

Behavior Changed: cross-origin iframes now use Permission Policy to access features​

Cross-origin iframes must now specify features available to a given iframe via the allow attribute in order to access them.

See documentation for more information.

Removed: The --disable-color-correct-rendering command line switch​

This switch was never formally documented but its removal is being noted here regardless. Chromium itself now has better support for color spaces so this flag should not be needed.

Behavior Changed: BrowserView.setAutoResize behavior on macOS​

In Electron 30, BrowserView is now a wrapper around the new WebContentsView API.

Previously, the setAutoResize function of the BrowserView API was backed by autoresizing on macOS, and by a custom algorithm on Windows and Linux. For simple use cases such as making a BrowserView fill the entire window, the behavior of these two approaches was identical. However, in more advanced cases, BrowserViews would be autoresized differently on macOS than they would be on other platforms, as the custom resizing algorithm for Windows and Linux did not perfectly match the behavior of macOS's autoresizing API. The autoresizing behavior is now standardized across all platforms.

If your app uses BrowserView.setAutoResize to do anything more complex than making a BrowserView fill the entire window, it's likely you already had custom logic in place to handle this difference in behavior on macOS. If so, that logic will no longer be needed in Electron 30 as autoresizing behavior is consistent.

Removed: params.inputFormType property on context-menu on WebContents​

The inputFormType property of the params object in the context-menu event from WebContents has been removed. Use the new formControlType property instead.

Entfernt: process.getIOCounters()​

Chromium has removed access to this information.

Ende der Unterstützung für 27.x.y​

Electron 27.x.y hat das Ende des Supports gemäß der Support-Richtlinie des Projekts erreicht. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

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.

Sie können die öffentliche Zeitleiste von Electron hier finden.

Weitere Informationen über zukünftige Änderungen können auf der Geplante Breaking Changes Seite gefunden werden.

We are excited to announce that Electron has been accepted as a mentoring organization for the 20th edition of Google Summer of Code (GSoC) 2024! Google Summer of Code is a global program focused on bringing new contributors into open source software development.

For more program details, check out 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 Electron core, we also work on a variety of projects to help sustain the Electron organization, such as:

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

As a Summer of Code contributor, you would be collaborating 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 examples in Electron Fiddle.

To learn more about Electron app distribution, you can also play around with Electron Forge by creating a sample application:

npm init electron-app@latest my-app

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

Drafting your proposal​

Interested in collaborating with Electron? First, check out the seven project idea drafts that we have prepared. Alle aufgeführten Ideen sind derzeit offen für Vorschläge.

Have a different idea you’d like us to consider? We’re also open to accepting new ideas that are not on the proposed project list, but make sure your approach is thoroughly outlined and detailed. When in doubt, we recommend sticking with our listed ideas.

Ihre Bewerbung sollte beinhalten:

• Your proposal: a written document that describes in detail what you plan to achieve over the course of the summer.
• Dein Hintergrund als Entwickler. 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. Note that proposals emailed to the Electron team rather than submitted through the application portal will not be considered as a final submission.

If you want more guidance on your proposal or are unsure of what to include, we also recommend that you follow the official Google Summer of Code proposal writing advice here.

Applications open on March 18th, 2024 and close on April 2nd, 2024.

Fragen?​

If you have questions we didn’t address in the blog post or inquiries for your proposal draft, please send us an email at summer-of-code@electronjs.org or check GSoC FAQ!

Ressourcen​

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

Electron 29.0.0 wurde veröffentlicht! It includes upgrades to Chromium 122.0.6261.39, V8 12.2, and Node.js 20.9.0.

Das Electron-Team freut sich, die Veröffentlichung von Electron 29.0.0 ankündigen zu können! Sie können es mit npm über npm electron@latest installieren oder von unserer Releases-Website herunterladen. Lesen Sie weiter für Details zu dieser Version.

Wenn Sie Feedback haben, teilen Sie es uns bitte auf Twitter oder Mastodon mit oder treten Sie unserem Community-Discord bei! Bugs und Feature-Anfragen können im Issue-Tracker von Electron gemeldet werden.

Bemerkenswerte Änderungen​

Highlights​

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

Stack-Änderungen​

• Chromium 122.0.6261.39
  • Neu in Chrome 122 und in DevTools 122
  • Neu in Chrome 121 und in DevTools 121
• Node 20.9.0
  • Anmerkungen zu Node 20.9.0
  • Anmerkungen zu Node 20.0.0
• V8 12.2

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.

Neue Funktionen​

• 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

Breaking Changes​

Behavior Changed: ipcRenderer can no longer be sent over the 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) => {
  /* ... */
});

Ende der Unterstützung für 26.x.y​

Electron 26.x.y hat das Ende des Supports gemäß der Support-Richtlinie des Projekts erreicht. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

Did you know that Electron recently added a community Request for Comments (RFC) process? If you want to add a feature to the framework, RFCs can be a useful tool to start a dialogue with maintainers on its design. You can also see upcoming changes being discussed in the Pull Requests. To learn more, check out our Introducing electron/rfcs blog post, or check out the README of the electron/rfcs repository directly.

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.

Sie können die öffentliche Zeitleiste von Electron hier finden.

Weitere Informationen über zukünftige Änderungen können auf der Geplante Breaking Changes Seite gefunden werden.

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.

Wie funktioniert das?​

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.

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!

• To see the list of active RFCs, refer to the text folder in the repository.
• To leave feedback on proposed RFCs, check out the list of open PRs.
• To submit a new RFC, check out the repo’s README and the RFC template.

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:

• Electron C APIs
• Preload Realm for Service Workers

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:

• emberjs/rfcs
• reactjs/rfcs
• rust-lang/rfcs
• tauri-apps/rfcs
• vuejs/rfcs
• yarnpkg/rfcs