Zum Inhalt springen

· Die Lesezeit beträgt 4 min

Electron 9.0.0 has been released! It includes upgrades to Chromium 83, V8 8.3, and Node.js 12.14. We've added several new API integrations for our spellchecker feature, enabled PDF viewer, and much more!


The Electron team is excited to announce the release of Electron 9.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

Notable Changes

Stack Changes

Highlight Features

  • Multiple improvements to the spellchecker feature. See more details in #22128 and #22368.
  • Improved window events handler efficiency on Linux. #23260.
  • Enable PDF viewer. #22131.

See the 9.0.0 release notes for a full list of new features and changes.

Breaking Changes

  • Deprecation warning when using remote without enableRemoteModule: true. #21546
    • This is the first step in our plans for deprecating the remote module and moving it to userland. You can read and follow this issue that details our reasons for this and includes a proposed timeline for deprecation.
  • Set app.enableRendererProcessReuse to true by default. #22336
    • This is continued work for a future requirement that native Node modules loaded in the renderer process be either N-API or Context Aware. Full info and proposed timeline is detailed in this issue.
  • Sending non-JavaScript objects over IPC now throws an exception. #21560
    • This behavior was depreciated in Electron 8.0. In Electron 9.0, the old serialization algorithm has been removed, and sending such non-serializable objects will now throw an "object could not be cloned" error.

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

API Changes

  • shell API changes:
    • The shell.openItem API has been replaced with an asynchronous shell.openPath API. proposal
  • sessionAPI changes:
    • Added session.listWordsFromSpellCheckerDictionary API to list custom words in the dictionary. #22128
    • Added session.removeWordFromSpellCheckerDictionary API to remove custom words in the dictionary. #22368
    • Added session.serviceWorkerContext API to access basic service worker info and receive console logs from service workers. #22313
  • app API changes:
    • Added a new force parameter to app.focus() on macOS to allow apps to forcefully take focus. #23447
  • BrowserWindow API changes:
    • Added support for property access to some getter/setter pairs on BrowserWindow. #23208

Deprecated APIs

The following APIs are now deprecated or removed:

  • shell.openItem API is now depreciated, and replaced with an asynchronous shell.openPath API.
  • <webview>.getWebContents, which was deprecated in Electron 8.0, is now removed.
  • webFrame.setLayoutZoomLevelLimits, which was deprecated in Electron 8.0, is now removed.

End of Support for 6.x.y

Electron 6.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. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 10.0.0 schedule maps out key dates in the Electron 10.0 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

Change the default of contextIsolation from false to true (Starting in Electron 10)

Without contextIsolation, any code running in a renderer process can quite easily reach into Electron internals or an app's preload script. That code can then perform privileged actions that Electron wants to keep restricted.

Changing this default improves the default security of Electron apps, so that apps will need to deliberately opt in to the insecure behaviour. Electron will depreciate the current default of contextIsolation in Electron 10.0, and change to the new default (true) in Electron 12.0.

For more information on contextIsolation, how to enable it easily and it's security benefits please see our dedicated Context Isolation Document.

· Eine Minute Lesezeit

Electron is temporarily pausing major releases


What's Happening?

Our major release cadence schedule moves in lockstep with that of Chromium, and the Chromium project has made the recent decision to pause its releases due to adjusted work schedules. This means that for the duration of Chromium's altered cadence, Electron will also temporarily pause new major releases.

We feel that our best choice is to follow in Chromium's footsteps, and so in the interim the Electron team will shift to full-time work on bugfixes, security, performance, and stability.

We want to ensure that both our maintainers and our consumers' wellbeing is prioritized during this time, so we welcome your feedback and look forward to returning to our regular release schedule.

For more updates, please follow our Twitter account.

Edit (2020-03-30): Electron 9 stable will target Chromium M83 and be released on May 19, 2020, in response to Chromium's announcement of skipping the M82 stable date and adjusting the M83 stable date.

· Die Lesezeit beträgt 6 min

Electron 8.0.0 has been released! It includes upgrades to Chromium 80, V8 8.0, and Node.js 12.13.0. We've added Chrome's built-in spellchecker, and much more!


The Electron team is excited to announce the release of Electron 8.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

Notable Changes

Stack Changes

Highlight Features

  • Implemented usage of Chrome's built-in spellchecker feature. See more details in #20692 and #21266.
  • IPC communication now uses v8's Structured Clone Algorithm. This is faster, more featureful, and less surprising than the existing logic, and brings about a 2x performance boost for large buffers and complex objects. Latency for small messages is not significantly affected. See more details in #20214.

See the 8.0.0 release notes for a full list of new features and changes.

Breaking Changes

  • Show module name in deprecation warning for context-aware modules. #21952
    • This is continued work for a future requirement that native Node modules loaded in the renderer process be either N-API or Context Aware. Full info and proposed timeline is detailed in this issue.
  • Values sent over IPC are now serialized with Structured Clone Algorithm. #20214
  • Offscreen Rendering is currently disabled due to lack of a maintainer to work on this feature. It broke during the Chromium upgrade and was subsequently disabled. #20772

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

API Changes

  • app API changes:
    • Added app.getApplicationNameForProtocol(url). #20399
    • Added app.showAboutPanel() and app.setAboutPanelOptions(options) support on Windows. #19420
  • BrowserWindow API changes:
    • Updated docs to note that BrowserWindow options hasShadow is available on all platforms #20038
    • Added trafficLightPosition option to BrowserWindow options to allow custom positioning for traffic light buttons. #21781
    • Added accessibleTitle option to BrowserWindow for setting the accessible window title #19698
    • BrowserWindow.fromWebContents() can now return null #19983
    • Added BrowserWindow.getMediaSourceId() and BrowserWindow.moveAbove(mediaSourceId). #18926
    • Added support for will-move event on macOS. #19641
  • Documented previously undocumented crashReporter.getCrashesDirectory(). #20417
  • dialog API changes:
    • Added dontAddToRecent property to dialog.showOpenDialog and dialog.showOpenDialogSync to prevent documents from being added to recent documents on Windows in open dialogs. #19669
    • Added property customization to dialog.showSaveDialog and dialog.showSaveDialogSync. #19672
  • Notification API changes:
    • Added timeoutType option to allow Linux/Windows users to set the type of notification timeout. #20153
    • Added urgency option to set urgency on Linux notifications. #20152
  • session API changes:
    • Updated documentation on session.setProxy(config) and session.setCertificateVerifyProc(proc) to note optional options. #19604
    • Added session.downloadURL(url) to allow to triggering downloads without a BrowserWindow. #19889
    • Added support for HTTP preconnect resource hints via session.preconnect(options) and the preconnect event. #18671
    • Added session.addWordToSpellCheckerDictionary to allow custom words in the dictionary #21297
  • Added option to shell.moveItemToTrash(fullPath[, deleteOnFail]) on macOS to specify what happens when moveItemToTrash fails. #19700
  • systemPreferences API changes:
    • Updated systemPreferences.getColor(color) documentation for macOS. #20611
    • Added screen media type to systemPreferences.getMediaAccessStatus(). #20764
  • Added nativeTheme.themeSource to allow apps to override Chromium and the OS's theme choice. #19960
  • TouchBar API changes:
    • Added accessibilityLabel property to TouchBarButton and TouchBarLabel to improve TouchBarButton/TouchBarLabel accessibility. #20454
    • Updated TouchBar related documentation #19444
  • tray API changes:
    • Added new options to tray.displayBalloon(): iconType, largeIcon, noSound and respectQuietTime. #19544
    • Added tray.removeBalloon(), which removes an already displayed balloon notification. #19547
    • Added tray.focus(), which returns focus to the taskbar notification area. feat: add tray.focus() #19548
  • webContents API changes:
    • Added contents.executeJavaScriptInIsolatedWorld(worldId, scripts[, userGesture]) to expose executeJavaScriptInIsolatedWorld on the webContents API. #21190
    • Added methods to capture a hidden webContents. #21679
    • Added options to webContents.print([options], [callback]) to enable customization of print page headers and footers. #19688
    • Added ability to inspect specific shared workers via webContents.getAllSharedWorkers() and webContents.inspectSharedWorkerById(workerId). #20389
    • Added the support of fitToPageEnabled and scaleFactor options in WebContents.printToPDF(). #20436
  • Updated webview.printToPDF documentation to indicate return type is now Uint8Array. #20505

Deprecated APIs

The following APIs are now deprecated:

  • Deprecated the nonfunctional visibleOnFullScreen option within BrowserWindow.setVisibleOnAllWorkspaces prior to its removal in the next major release version. #21732
  • Deprecated alternate-selected-control-text on systemPreferences.getColor(color) for macOS. #20611
  • Deprecated setLayoutZoomLevelLimits on webContents, webFrame, and <webview> Tag because Chromium removed this capability. #21296
  • The default value of false for app.allowRendererProcessReuse is now deprecated. #21287
  • Deprecated <webview>.getWebContents() as it depends on the remote module. #20726

End of Support for 5.x.y

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

App Feedback Programm

We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.

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. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 9.0.0 schedule maps out key dates in the Electron 9 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

Deprecation of remote Module (Starting in Electron 9)

Due to serious security liabilities, we are beginning plans to deprecate the remote module starting in Electron 9. You can read and follow this issue that details our reasons for this and includes a proposed timeline for deprecation.

· Die Lesezeit beträgt 2 min

At Node+JS Interactive in Montreal, the OpenJS Foundation announced that it accepted Electron into the Foundation's incubation program. The Foundation is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects, as well as collaboratively fund activities for the benefit of the community at large.

The OpenJS Foundation is host to a number of open source JavaScript projects including jQuery, Node.js, and webpack. It's supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft. Electron is an open–source framework for building cross-platform desktop applications with web technologies.

This is an exciting move for Electron, and we see it as a next step in our evolution as an open-source project.


What this means for developers

Electron joining the OpenJS Foundation does not change how Electron is made, released, or used — and does not directly affect developers building applications with Electron. Even though Electron was originally created at GitHub in 2013, it is currently maintained by a number of organizations and individuals. In 2019, Electron codified its governance structure and invested heavily into formalizing how decisions affecting the entire project are made. We believe that having multiple organizations and developers investing in and collaborating on Electron makes the project stronger.

Lifting Electron up from being owned by a single corporate entity and moving it into a neutral foundation focused on supporting the web and JavaScript ecosystem is a natural next step as we mature as an open-source project.

Learning more

You can read up on the foundation, its mission, and its members on the OpenJSF website. For more information and quotes about the acceptance of Electron into the OpenJSF incubation program, check out the official press release. To learn more about the humans behind Electron and how they work together, take a look at our Governance page.

To get started with Electron itself, take a peek at our documentation.

· Eine Minute Lesezeit

A High severity vulnerability has been discovered in Chrome which affects all software based on Chromium, including Electron.

This vulnerability has been assigned CVE-2019-13720. Mehr dazu erfahren Sie im Chrome Blog Post.

Please note that Chrome has reports of this vulnerability being used in the wild so it is strongly recommended you upgrade Electron as soon as possible.


Scope

This affects any Electron application that may run third-party or untrusted JavaScript.

Mitigation

Affected apps should upgrade to a patched version of Electron.

We've published new versions of Electron which include fixes for this vulnerability:

Electron 7.0.1 automatically included the fix from upstream, before the announcement was made. Electron 8 is similarly unaffected. The vulnerability did not exist in Electron 5, so that version is also unaffected.

Further Information

This vulnerability was discovered by Anton Ivanov and Alexey Kulaev at Kaspersky Labs and reported to the Chrome team. Der Chrome Blog Beitrag kann hier gefunden werden.

Um mehr über Best Practices für die Sicherheit Ihrer Electron-Apps zu erfahren, lesen Sie unsere -Sicherheitshinweise.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

· Die Lesezeit beträgt 3 min

Electron 7.0.0 has been released! Es enthält Upgrades auf Chromium 78, V8 7.8 und Node.js 12.8.1. Wir haben ein Fenster auf Arm 64 Release hinzugefügt, schnellere IPC-Methoden, eine nativeTheme API und vieles mehr!


The Electron team is excited to announce the release of Electron 7.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

Notable Changes

  • Stack Upgrades:

    StackVersion in Electron 6Version in Electron 7What's New
    Chromium76.0.3809.14678.0.3905.177, 78
    V87.67.87.7, 7.8
    Node.js12.4.012.8.112.5, 12.6, 12.7, 12.8, 12.8.1
  • Added Windows on Arm (64 bit) release. #18591, #20112

  • Added ipcRenderer.invoke() and ipcMain.handle() for asynchronous request/response-style IPC. These are strongly recommended over the remote module. See this "Electron’s ‘remote’ module considered harmful" blog post for more information. #18449

  • Added nativeTheme API to read and respond to changes in the OS's theme and color scheme. #19758, #20486

  • Switched to a new TypeScript Definitions generator. The resulting definitions are more precise; so if your TypeScript build fails, this is the likely cause. #18103

See the 7.0.0 release notes for a longer list of changes.

Breaking Changes

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

  • Removed deprecated APIs:
    • Callback-based versions of functions that now use Promises. #17907
    • Tray.setHighlightMode() (macOS). #18981
    • app.enableMixedSandbox() #17894
    • app.getApplicationMenu(),
    • app.setApplicationMenu(),
    • powerMonitor.querySystemIdleState(),
    • powerMonitor.querySystemIdleTime(),
    • webFrame.setIsolatedWorldContentSecurityPolicy(),
    • webFrame.setIsolatedWorldHumanReadableName(),
    • webFrame.setIsolatedWorldSecurityOrigin() #18159
  • Session.clearAuthCache() no longer allows filtering the cleared cache entries. #17970
  • Native interfaces on macOS (menus, dialogs, etc.) now automatically match the dark mode setting on the user's machine. #19226
  • Updated the electron module to use @electron/get. The minimum supported node version is now Node 8. #18413
  • The file electron.asar no longer exists. Any packaging scripts that depend on its existence should be updated. #18577

End of Support for 4.x.y

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

App Feedback Programm

We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.

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. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 8.0.0 schedule maps out key dates in the Electron 8 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

· Die Lesezeit beträgt 4 min

The Electron team is excited to announce the release of Electron 6.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!


What's New

Today marks a first for the Electron project: this is the first time we've made a stable Electron release on the same day as the corresponding Chrome stable release! 🎉

Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 6:

This release also includes improvements to Electron's APIs. The release notes have a more complete list, but here are the highlights:

Promisification

Electron 6.0 continues the modernization initiative started in 5.0 to improve Promise support.

These functions now return Promises and still support older callback-based invocation:

  • contentTracing.getCategories() #16583
  • contentTracing.getCategories() #16583
  • contentTracing.getTraceBufferUsage() #16600
  • contents.executeJavaScript() #17312
  • cookies.flushStore() #16464
  • cookies.get() #16464
  • cookies.remove() #16464
  • cookies.set() #16464
  • dialog.showCertificateTrustDialog() #17181
  • inAppPurchase.getProducts() #17355
  • inAppPurchase.purchaseProduct()#17355
  • netLog.stopLogging() #16862
  • session.clearAuthCache() #17259
  • session.clearCache() #17185
  • session.clearHostResolverCache() #17229
  • session.clearStorageData() #17249
  • session.getBlobData() #17303
  • session.getCacheSize() #17185
  • session.resolveProxy() #17222
  • session.setProxy() #17222
  • webContents.hasServiceWorker() #16535
  • webContents.printToPDF() #16795
  • webContents.savePage() #16742
  • webFrame.executeJavaScript() #17312
  • webFrame.executeJavaScriptInIsolatedWorld() #17312
  • webviewTag.executeJavaScript() #17312

These functions now have two forms, synchronous and Promise-based asynchronous:

  • dialog.showMessageBox()/dialog.showMessageBoxSync() #17298
  • dialog.showOpenDialog()/dialog.showOpenDialogSync() #16973
  • dialog.showSaveDialog()/dialog.showSaveDialogSync() #17054

These functions now return Promises:

Electron Helper (Renderer).app, Electron Helper (GPU).app and Electron Helper (Plugin).app

In order to enable the hardened runtime, which restricts things like writable-executable memory and loading code signed by a different Team ID, special code signing entitlements needed to be granted to the Helper.

To keep these entitlements scoped to the process types that require them, Chromium added three new variants of the Helper app: one for renderers (Electron Helper (Renderer).app), one for the GPU process (Electron Helper (GPU).app) and one for plugins (Electron Helper (Plugin).app).

Folks using electron-osx-sign to codesign their Electron app shouldn't have to make any changes to their build logic. If you're codesigning your app with custom scripts, you should ensure that the three new Helper applications are correctly codesigned.

In order to package your application correctly with these new helpers you need to be using electron-packager@14.0.4 or higher. If you are using electron-builder you should follow this issue to track support for these new helpers.

Breaking Changes

  • This release begins laying the groundwork for a future requirement that native Node modules loaded in the renderer process be either N-API or Context Aware. The reasons for this change are faster performance, stronger security, and reduced maintenance workload. Read the full details including the proposed timeline in this issue. This change is expected to be completed in Electron v11.

  • net.IncomingMessage headers have changed slightly to more closely match Node.js behavior, particularly with the value of set-cookie and how duplicate headers are handled. #17517.

  • shell.showItemInFolder() now returns void and is an asynchronous call. #17121

  • Apps must now explicitly set a log path by calling the new function app.setAppLogPath() before using app.getPath('log'). #17841

End of Support for 3.x.y

Per our support policy, 3.x.y has reached end of life. Developers and applications are encouraged to upgrade to a newer version of Electron.

App Feedback Programm

We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.

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. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 7.0.0 schedule maps out key dates in the Electron 7 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

· Die Lesezeit beträgt 3 min
⚡️ Update (14.07.2021): Wir werden noch schneller!

In Q3 2021, das Chrome team hat ihre Release Zeiträume von 6 Wochen auf 4 Wochen erhöht. Electron's releases have followed suit. Please read the updated 8 week cadence blog post for more up-to-date information!

🎉 Electron is moving to release a new major stable version every 12 weeks! 🎉


⚡️ Wow that's quick! But why?

Simply put, Chromium doesn't stop shipping so Electron is not going to slow down either.

Chromium releases on a consistent 6-week schedule. To deliver the most up-to-date versions of Chromium in Electron, our schedule needs to track theirs. More information around Chromium's release cycle can be found here.

🚀 Why every 12 weeks?

Every 6 weeks, a new Chromium release comes out with new features, bug fixes / security fixes, and V8 improvements. Electron's users have been loud and clear about wanting these changes in a timely manner, so we've adjusted our stable release dates to match every other Chromium stable release. Up first, Electron v6.0.0 will include M76 and is scheduled for stable release on July 30, 2019, the same release day as Chromium M76.

🚧 What does this mean for me and my Electron app?

You'll have access to new Chromium and V8 features and fixes sooner than before. Importantly, you'll also know when those new changes are coming, so you'll be able to plan with better information than before.

The Electron team will continue to support the latest three major versions. For example, when v6.0.0 goes stable on July 30, 2019, we will support v6.x, v5.x, and v4.x, while v3.x will reach End-Of-Life.

💬 App Feedback Programm

Please consider joining our App Feedback Program to help us with testing our beta releases and stabilization. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release.

📝 A brief history of Electron releases

The decisions around stable releases before v3.0.0 did not follow a schedule. Wir haben dem Projekt interne Zeitpläne mit v3.0.0 und v4.0.0 hinzugefügt. Anfang dieses Jahres haben wir beschlossen, unser Stable-Veröffentlichungsdatum zum ersten Mal für Electron v5.0.0 bekannt zu geben. Announcing our stable release dates was positively received overall and we're excited to continue doing that for future releases.

In order to better streamline these upgrade-related efforts, our Upgrades and Releases Working Groups were created within our Governance system. They have allowed us to better prioritize and delegate this work, which we hope will become more apparent with each subsequent release.

Here is where our new cadence will put us in comparison to Chromium's cadence:

line graph comparing Electron versus Chromium versions

📨 If you have questions, please mail us at info@electronjs.org.

· Die Lesezeit beträgt 4 min

The Electron team is excited to announce the release of Electron 5.0.0! You can install it with npm via npm install electron@latest or download the tarballs from our releases page. The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!


What's New?

Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 5:

Electron 5 also includes improvements to Electron-specific APIs. A summary of the major changes is below; for the full list of changes, check out the Electron v5.0.0 release notes.

Promisification

Electron 5 continues Promisification initiative initiative to convert Electron's callback-based API to use Promises. These APIs were converted for Electron 5:

  • app.getFileIcon
  • contentTracing.getCategories
  • contentTracing.startRecording
  • contentTracing.stopRecording
  • debugger.sendCommand
  • Cookies API
  • shell.openExternal
  • webContents.loadFile
  • webContents.loadURL
  • webContents.zoomLevel
  • webContents.zoomFactor
  • win.capturePage

System colors access for macOS

These functions were changed or added to systemPreferences to access macOS systems' colors:

  • systemPreferences.getAccentColor
  • systemPreferences.getColor
  • systemPreferences.getSystemColor

Process memory information

The function process.getProcessMemoryInfo has been added to get memory usage statistics about the current process.

Additional filtering for remote APIs

To improve security in the remote API, new remote events have been added so that remote.getBuiltin, remote.getCurrentWindow, remote.getCurrentWebContents and <webview>.getWebContents can be filtered.

Multiple BrowserViews on BrowserWindow

BrowserWindow now supports managing multiple BrowserViews within the same BrowserWindow.

Breaking Changes

Defaults for packaged apps

Packaged apps will now behave the same as the default app: a default application menu will be created unless the app has one and the window-all-closed event will be automatically handled unless the app handles the event.

Mixed sandbox

Mixed sandbox mode is now enabled by default. Renderers launched with sandbox: true will now be actually sandboxed, where previously they would only be sandboxed if mixed-sandbox mode was also enabled.

Security improvements

The default values of nodeIntegration and webviewTag are now false to improve security.

Spellchecker now asynchronous

The SpellCheck API has been changed to provide asynchronous results.

Deprecations

The following APIs are newly deprecated in Electron 5.0.0 and planned for removal in 6.0.0:

Mksnapshot binaries for arm and arm64

Native Binärdateien von mksnapshot für Arm und arm64 sind veraltet und werden in 6 entfernt. .0. Snapshots können für Arm und arm64 mit den x64 Binärdateien erstellt werden.

ServiceWorker APIs on WebContents

Deprecated ServiceWorker APIs on WebContents in preparation for their removal.

  • webContents.hasServiceWorker
  • webContents.unregisterServiceWorker

Automatic modules with sandboxed webContents

In order to improve security, the following modules are being deprecated for use directly via require and will instead need to be included via remote.require in a sandboxed webcontents:

  • electron.screen
  • child_process
  • fs
  • os
  • pfad

webFrame Isolated World APIs

webFrame.setIsolatedWorldContentSecurityPolicy,webFrame.setIsolatedWorldHumanReadableName, webFrame.setIsolatedWorldSecurityOrigin have been deprecated in favor of webFrame.setIsolatedWorldInfo.

Mixed sandbox

enableMixedSandbox and the --enable-mixed-sandbox command-line switch still exist for compatibility, but are deprecated and have no effect.

End of support for 2.0.x

Per our supported versions policy, 2.0.x has reached end of life.

App Feedback Programm

We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.

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. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 6.0.0 schedule maps out key dates in the Electron 6 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

· Die Lesezeit beträgt 4 min

How do Electron's features written in C++ or Objective-C get to JavaScript so they're available to an end-user?


Background

Electron is a JavaScript platform whose primary purpose is to lower the barrier to entry for developers to build robust desktop apps without worrying about platform-specific implementations. However, at its core, Electron itself still needs platform-specific functionality to be written in a given system language.

In reality, Electron handles the native code for you so that you can focus on a single JavaScript API.

How does that work, though? How do Electron's features written in C++ or Objective-C get to JavaScript so they're available to an end-user?

To trace this pathway, let's start with the app module.

By opening the app.ts file inside our lib/ directory, you'll find the following line of code towards the top:

const binding = process.electronBinding('app')

This line points directly to Electron's mechanism for binding its C++/Objective-C modules to JavaScript for use by developers. This function is created by the header and implementation file for the ElectronBindings class.

process.electronBinding

These files add the process.electronBinding function, which behaves like Node.js’ process.binding. process.binding is a lower-level implementation of Node.js' require() method, except it allows users to require native code instead of other code written in JS. This custom process.electronBinding function confers the ability to load native code from Electron.

When a top-level JavaScript module (like app) requires this native code, how is the state of that native code determined and set? Where are the methods exposed up to JavaScript? What about the properties?

native_mate

At present, answers to this question can be found in native_mate: a fork of Chromium's gin library that makes it easier to marshal types between C++ and JavaScript.

Inside native_mate/native_mate there's a header and implementation file for object_template_builder. This is what allow us to form modules in native code whose shape conforms to what JavaScript developers would expect.

mate::ObjectTemplateBuilder

If we look at every Electron module as an object, it becomes easier to see why we would want to use object_template_builder to construct them. This class is built on top of a class exposed by V8, which is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++. V8 implements the JavaScript (ECMAScript) specification, so its native functionality implementations can be directly correlated to implementations in JavaScript. For example, v8::ObjectTemplate gives us JavaScript objects without a dedicated constructor function and prototype. It uses Object[.prototype], and in JavaScript would be equivalent to Object.create().

To see this in action, look to the implementation file for the app module, atom_api_app.cc. At the bottom is the following:

mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
.SetMethod("getGPUInfo", &App::GetGPUInfo)

In the above line, .SetMethod is called on mate::ObjectTemplateBuilder. .SetMethod can be called on any instance of the ObjectTemplateBuilder class to set methods on the Object prototype in JavaScript, with the following syntax:

.SetMethod("method_name", &function_to_bind)

This is the JavaScript equivalent of:

function App{}
App.prototype.getGPUInfo = function () {
// implementation here
}

This class also contains functions to set properties on a module:

.SetProperty("property_name", &getter_function_to_bind)

oder

.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)

These would in turn be the JavaScript implementations of Object.defineProperty:

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
get() {
return _myProperty
}
})

und

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
get() {
return _myProperty
}
set(newPropertyValue) {
_myProperty = newPropertyValue
}
})

It’s possible to create JavaScript objects formed with prototypes and properties as developers expect them, and more clearly reason about functions and properties implemented at this lower system level!

The decision around where to implement any given module method is itself a complex and oft-nondeterministic one, which we'll cover in a future post.