Skip to main content

December Quiet Month (Dec'23)

· 2 min read

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

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. Electron 28.0.0 will be released on December 5th. After Electron 28, there will be no new Stable 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.

Going forward

This is our third year running our quiet period experiment, and we've had a lot of success so far in balancing a month of rest with maintaining our normal release cadence afterwards. Therefore, we've decided to make this a regular part of our release calendar going forward. We'll still be putting a reminder into the last stable release of every calendar year.

See you all in 2024!

Electron 27.0.0

· 3 min read

Electron 27.0.0 has been released! It includes upgrades to Chromium 118.0.5993.32, V8 11.8, and Node.js 18.17.1.


The Electron team is excited to announce the release of Electron 27.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

Stack Changes

Breaking Changes

Removed: macOS 10.13 / 10.14 support

macOS 10.13 (High Sierra) and macOS 10.14 (Mojave) are no longer supported by Chromium.

Older versions of Electron will continue to run on these operating systems, but macOS 10.15 (Catalina) or later will be required to run Electron v27.0.0 and higher.

Deprecated: ipcRenderer.sendTo()

The ipcRenderer.sendTo() API has been deprecated. It should be replaced by setting up a MessageChannel between the renderers.

The senderId and senderIsMainFrame properties of IpcRendererEvent have been deprecated as well.

Removed: color scheme events in systemPreferences

The following systemPreferences events have been removed:

  • inverted-color-scheme-changed
  • high-contrast-color-scheme-changed

Use the new updated event on the nativeTheme module instead.

// Removed
systemPreferences.on('inverted-color-scheme-changed', () => {
/* ... */
});
systemPreferences.on('high-contrast-color-scheme-changed', () => {
/* ... */
});

// Replace with
nativeTheme.on('updated', () => {
/* ... */
});

Removed: webContents.getPrinters

The webContents.getPrinters method has been removed. Use webContents.getPrintersAsync instead.

const w = new BrowserWindow({ show: false });

// Removed
console.log(w.webContents.getPrinters());
// Replace with
w.webContents.getPrintersAsync().then((printers) => {
console.log(printers);
});

Removed: systemPreferences.{get,set}AppLevelAppearance and systemPreferences.appLevelAppearance

The systemPreferences.getAppLevelAppearance and systemPreferences.setAppLevelAppearance methods have been removed, as well as the systemPreferences.appLevelAppearance property. Use the nativeTheme module instead.

// Removed
systemPreferences.getAppLevelAppearance();
// Replace with
nativeTheme.shouldUseDarkColors;

// Removed
systemPreferences.appLevelAppearance;
// Replace with
nativeTheme.shouldUseDarkColors;

// Removed
systemPreferences.setAppLevelAppearance('dark');
// Replace with
nativeTheme.themeSource = 'dark';

Removed: alternate-selected-control-text value for systemPreferences.getColor

The alternate-selected-control-text value for systemPreferences.getColor has been removed. Use selected-content-background instead.

// Removed
systemPreferences.getColor('alternate-selected-control-text');
// Replace with
systemPreferences.getColor('selected-content-background');

New Features

  • Added app accessibility transparency settings api #39631
  • Added support for chrome.scripting extension APIs #39675
  • Enabled WaylandWindowDecorations by default #39644

End of Support for 24.x.y

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

E27 (Oct'23)E28 (Dec'23)E29 (Feb'24)
27.x.y28.x.y29.x.y
26.x.y27.x.y28.x.y
25.x.y26.x.y27.x.y

End of Extended Support for 22.x.y

Earlier this year, the Electron team extended Electron 22's planned end of life date from May 30, 2023 to October 10, 2023, in order to match Chrome's extended support for Windows 7/8/8.1 (see Farewell, Windows 7/8/8.1 for more details).

Electron 22.x.y has reached end-of-support as per the project's support policy and this support extension. This will drop support back to the latest three stable major versions, and will end official support for Windows 7/8/8.1.

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.

You can find Electron's public timeline here.

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

Breach to Barrier: Strengthening Apps with the Sandbox

· 4 min read

It’s been more than a week since CVE-2023-4863: Heap buffer overflow in WebP was made public, leading to a flurry of new releases of software rendering webp images: macOS, iOS, Chrome, Firefox, and various Linux distributions all received updates. This followed investigations by Citizen Lab, discovering that an iPhone used by a “Washington DC-based civil society organization” was under attack using a zero-click exploit within iMessage.

Electron, too, spun into action and released new versions the same day: If your app renders any user-provided content, you should update your version of Electron - v27.0.0-beta.2, v26.2.1, v25.8.1, v24.8.3, and v22.3.24 all contain a fixed version of libwebp, the library responsible for rendering webp images.

Now that we are all freshly aware that an interaction as innocent as “rendering an image” is a potentially dangerous activity, we want to use this opportunity to remind everyone that Electron comes with a process sandbox that will limit the blast radius of the next big attack — whatever it may be.

The sandbox was available ever since Electron v1 and enabled by default in v20, but we know that many apps (especially those that have been around for a while) may have a sandbox: false somewhere in their code – or a nodeIntegration: true, which equally disables the sandbox when there is no explicit sandbox setting. That’s understandable: If you’ve been with us for a long time, you probably enjoyed the power of throwing a require("child_process") or require("fs") into the same code that runs your HTML/CSS.

Before we talk about how you migrate to the sandbox, let’s first discuss why you want it.

The sandbox puts a hard cage around all renderer processes, ensuring that no matter what happens inside, code is executed inside a restricted environment. As a concept, it's a lot older than Chromium, and provided as a feature by all major operating systems. Electron's and Chromium's sandbox build on top of these system features. Even if you never display user-generated content, you should consider the possibility that your renderer might get compromised: Scenarios as sophisticated as supply chain attacks and as simple as little bugs can lead to your renderer doing things you didn't fully intend for it to do.

The sandbox makes that scenario a lot less scary: A process inside gets to freely use CPU cycles and memory — that’s it. Processes cannot write to disk or display their own windows. In the case of our libwep bug, the sandbox makes sure that an attacker cannot install or run malware. In fact, in the case of the original Pegasus attack on the employee’s iPhone, the attack specifically targeted a non-sandboxed image process to gain access to the phone, first breaking out of the boundaries of the normally sandboxed iMessage. When a CVE like the one in this example is announced, you still have to upgrade your Electron apps to a secure version — but in the meantime, the amount of damage an attacker can do is limited dramatically.

Migrating a vanilla Electron application from sandbox: false to sandbox: true is an undertaking. I know, because even though I have personally written the first draft of the Electron Security Guidelines, I have not managed to migrate one of my own apps to use it. That changed this weekend, and I recommend that you change it, too.

Don’t be scared by the number of line changes, most of it is in package-lock.json

There are two things you need to tackle:

  1. If you’re using Node.js code in either preload scripts or the actual WebContents, you need to move all that Node.js interaction to the main process (or, if you are fancy, a utility process). Given how powerful renderers have become, chances are high that the vast majority of your code doesn’t really need refactoring.

    Consult our documentation on Inter-Process Communication. In my case, I moved a lot of code and wrapped it in ipcRenderer.invoke() and ipcMain.handle(), but the process was straightforward and quickly done. Be a little mindful of your APIs here - if you build an API called executeCodeAsRoot(code), the sandbox won't protect your users much.

  2. Since enabling the sandbox disables Node.js integration in your preload scripts, you can no longer use require("../my-script"). In other words, your preload script needs to be a single file.

    There are multiple ways to do that: Webpack, esbuild, parcel, and rollup will all get the job done. I used Electron Forge’s excellent Webpack plugin, users of the equally popular electron-builder can use electron-webpack.

All in all, the entire process took me around four days — and that includes a lot of scratching my head at how to wrangle Webpack’s massive power, since I decided to use the opportunity to refactor my code in plenty of other ways, too.

Electron 26.0.0

· 2 min read

Electron 26.0.0 has been released! It includes upgrades to Chromium 116.0.5845.62, V8 11.2, and Node.js 18.16.1. Read below for more details!


The Electron team is excited to announce the release of Electron 26.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 join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes

Stack Changes

Breaking Changes

Deprecated: webContents.getPrinters

The webContents.getPrinters method has been deprecated. Use webContents.getPrintersAsync instead.

const w = new BrowserWindow({ show: false });

// Deprecated
console.log(w.webContents.getPrinters());
// Replace with
w.webContents.getPrintersAsync().then((printers) => {
console.log(printers);
});

Deprecated: systemPreferences.{get,set}AppLevelAppearance and systemPreferences.appLevelAppearance

The systemPreferences.getAppLevelAppearance and systemPreferences.setAppLevelAppearance methods have been deprecated, as well as the systemPreferences.appLevelAppearance property. Use the nativeTheme module instead.

// Deprecated
systemPreferences.getAppLevelAppearance();
// Replace with
nativeTheme.shouldUseDarkColors;

// Deprecated
systemPreferences.appLevelAppearance;
// Replace with
nativeTheme.shouldUseDarkColors;

// Deprecated
systemPreferences.setAppLevelAppearance('dark');
// Replace with
nativeTheme.themeSource = 'dark';

Deprecated: alternate-selected-control-text value for systemPreferences.getColor

The alternate-selected-control-text value for systemPreferences.getColor has been deprecated. Use selected-content-background instead.

// Deprecated
systemPreferences.getColor('alternate-selected-control-text');
// Replace with
systemPreferences.getColor('selected-content-background');

New Features

  • Added safeStorage.setUsePlainTextEncryption and safeStorage.getSelectedStorageBackend api. #39107
  • Added safeStorage.setUsePlainTextEncryption and safeStorage.getSelectedStorageBackend api. #39155
  • Added senderIsMainFrame to messages sent via ipcRenderer.sendTo(). #39206
  • Added support for flagging a Menu as being keyboard initiated. #38954

End of Support for 23.x.y

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

E26 (Aug'23)E27 (Oct'23)E28 (Jan'24)
26.x.y27.x.y28.x.y
25.x.y26.x.y27.x.y
24.x.y25.x.y26.x.y
22.x.y

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.

You can find Electron's public timeline here.

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

Electron 25.0.0

· 5 min read

Electron 25.0.0 has been released! It includes upgrades to Chromium 114, V8 11.4, and Node.js 18.15.0. Read below for more details!


The Electron team is excited to announce the release of Electron 25.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 join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes

Highlights

  • Implemented net.fetch within Electron's net module, using Chromium's networking stack. This differs from Node's fetch(), which uses Node.js' HTTP stack. See #36733 and #36606.
  • Added protocol.handle, which replaces and deprecates protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol. #36674
  • Extended support for Electron 22, in order to match Chromium and Microsoft's Windows 7/8/8.1 deprecation plan. See additional details at the end of this blog post.

Stack Changes

Breaking Changes

Deprecated: protocol.{register,intercept}{Buffer,String,Stream,File,Http}Protocol

The protocol.register*Protocol and protocol.intercept*Protocol methods have been replaced with protocol.handle.

The new method can either register a new protocol or intercept an existing protocol, and responses can be of any type.

// Deprecated in Electron 25
protocol.registerBufferProtocol('some-protocol', () => {
callback({ mimeType: 'text/html', data: Buffer.from('<h5>Response</h5>') });
});

// Replace with
protocol.handle('some-protocol', () => {
return new Response(
Buffer.from('<h5>Response</h5>'), // Could also be a string or ReadableStream.
{ headers: { 'content-type': 'text/html' } }
);
});
// Deprecated in Electron 25
protocol.registerHttpProtocol('some-protocol', () => {
callback({ url: 'https://electronjs.org' });
});

// Replace with
protocol.handle('some-protocol', () => {
return net.fetch('https://electronjs.org');
});
// Deprecated in Electron 25
protocol.registerFileProtocol('some-protocol', () => {
callback({ filePath: '/path/to/my/file' });
});

// Replace with
protocol.handle('some-protocol', () => {
return net.fetch('file:///path/to/my/file');
});

Deprecated: BrowserWindow.setTrafficLightPosition(position)

BrowserWindow.setTrafficLightPosition(position) has been deprecated, the BrowserWindow.setWindowButtonPosition(position) API should be used instead which accepts null instead of { x: 0, y: 0 } to reset the position to system default.

// Deprecated in Electron 25
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// Replace with
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

Deprecated: BrowserWindow.getTrafficLightPosition()

BrowserWindow.getTrafficLightPosition() has been deprecated, the BrowserWindow.getWindowButtonPosition() API should be used instead which returns null instead of { x: 0, y: 0 } when there is no custom position.

// Deprecated in Electron 25
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
// No custom position.
}

// Replace with
const ret = win.getWindowButtonPosition();
if (ret === null) {
// No custom position.
}

New Features

  • Added net.fetch(). #36733
    • net.fetch supports requests to file: URLs and custom protocols registered with protocol.register*Protocol. #36606
  • Added BrowserWindow.set/getWindowButtonPosition APIs. #37094
  • Added protocol.handle, replacing and deprecating protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol. #36674
  • Added a will-frame-navigate event to webContents and the <webview> tag, which fires whenever any frame within the frame hierarchy attempts to navigate. #34418
  • Added initiator information to navigator events. This information allows distinguishing window.open from a parent frame causing a navigation, as opposed to a child-initiated navigation. #37085
  • Added net.resolveHost that resolves hosts using defaultSession object. #38152
  • Added new 'did-resign-active' event to app. #38018
  • Added several standard page size options to webContents.print(). #37159
  • Added the enableLocalEcho flag to the session handler ses.setDisplayMediaRequestHandler() callback for allowing remote audio input to be echoed in the local output stream when audio is a WebFrameMain. #37315
  • Added thermal management information to powerMonitor. #38028
  • Allows an absolute path to be passed to the session.fromPath() API. #37604
  • Exposes the audio-state-changed event on webContents. #37366

22.x.y Continued Support

As noted in Farewell, Windows 7/8/8.1, Electron 22's (Chromium 108) planned end of life date will be extended from May 30, 2023 to October 10, 2023. The Electron team will continue to backport any security fixes that are part of this program to Electron 22 until October 10, 2023. The October support date follows the extended support dates from both Chromium and Microsoft. On October 11, the Electron team will drop support back to the latest three stable major versions, which will no longer support Windows 7/8/8.1.

E25 (May'23)E26 (Aug'23)E27 (Oct'23)
25.x.y26.x.y27.x.y
24.x.y25.x.y26.x.y
23.x.y24.x.y25.x.y
22.x.y22.x.y--

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.

You can find Electron's public timeline here.

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

Electron 24.0.0

· 4 min read

Electron 24.0.0 has been released! It includes upgrades to Chromium 112.0.5615.49, V8 11.2, and Node.js 18.14.0. Read below for more details!


The Electron team is excited to announce the release of Electron 24.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 join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes

Stack Changes

Breaking Changes

API Changed: nativeImage.createThumbnailFromPath(path, size)

The maxSize parameter has been changed to size to reflect that the size passed in will be the size the thumbnail created. Previously, Windows would not scale the image up if it were smaller than maxSize, and macOS would always set the size to maxSize. Behavior is now the same across platforms.

// a 128x128 image.
const imagePath = path.join('path', 'to', 'capybara.png');

// Scaling up a smaller image.
const upSize = { width: 256, height: 256 };
nativeImage.createThumbnailFromPath(imagePath, upSize).then((result) => {
console.log(result.getSize()); // { width: 256, height: 256 }
});

// Scaling down a larger image.
const downSize = { width: 64, height: 64 };
nativeImage.createThumbnailFromPath(imagePath, downSize).then((result) => {
console.log(result.getSize()); // { width: 64, height: 64 }
});

New Features

  • Added the ability to filter HttpOnly cookies with cookies.get(). #37365
  • Added logUsage to shell.openExternal() options, which allows passing the SEE_MASK_FLAG_LOG_USAGE flag to ShellExecuteEx on Windows. The SEE_MASK_FLAG_LOG_USAGE flag indicates a user initiated launch that enables tracking of frequently used programs and other behaviors. #37291
  • Added types to the webRequest filter, adding the ability to filter the requests you listen to.#37427
  • Added a new devtools-open-url event to webContents to allow developers to open new windows with them. #36774
  • Added several standard page size options to webContents.print(). #37265
  • Added the enableLocalEcho flag to the session handler ses.setDisplayMediaRequestHandler() callback for allowing remote audio input to be echoed in the local output stream when audio is a WebFrameMain. #37528
  • Allow an application-specific username to be passed to inAppPurchase.purchaseProduct(). #35902
  • Exposed window.invalidateShadow() to clear residual visual artifacts on macOS. #32452
  • Whole-program optimization is now enabled by default in electron node headers config file, allowing the compiler to perform opimizations with information from all modules in a program as opposed to a per-module (compiland) basis. #36937
  • SystemPreferences::CanPromptTouchID (macOS) now supports Apple Watch. #36935

End of Support for 21.x.y

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

As noted in Farewell, Windows 7/8/8.1, Electron 22's (Chromium 108) planned end of life date will be extended from May 30, 2023 to October 10, 2023. The Electron team will continue to backport any security fixes that are part of this program to Electron 22 until October 10, 2023.

E24 (Apr'23)E25 (May'23)E26 (Aug'23)
24.x.y25.x.y26.x.y
23.x.y24.x.y25.x.y
22.x.y23.x.y24.x.y
--22.x.y22.x.y

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.

You can find Electron's public timeline here.

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

10 years of Electron 🎉

· 10 min read

The first commit to the electron/electron repository was on March 13, 20131.

Initial commit on electron/electron by @aroben

10 years and 27,147 more commits from 1192 unique contributors later, Electron has become one of the most popular frameworks for building desktop applications today. This milestone is the perfect opportunity to celebrate and reflect on our journey so far, and to share what we’ve learned along the way.

We would not be here today without everyone who has dedicated their time and effort to contribute to the project. Although source code commits are always the most visible contributions, we also have to acknowledge the effort of folks who report bugs, maintain userland modules, provide documentation and translations, and participate in the Electron community across cyberspace. Every contribution is invaluable to us as maintainers.

Before we continue with the rest of the blog post: thank you. ❤️

How did we get here?

Atom Shell was built as the backbone for GitHub’s Atom editor, which launched in public beta in April 2014. It was built from the ground up as an alternative to the web-based desktop frameworks available at the time (node-webkit and Chromium Embedded Framework). It had a killer feature: embedding Node.js and Chromium to provide a powerful desktop runtime for web technologies.

Within a year, Atom Shell began seeing immense growth in capabilities and popularity. Large companies, startups, and individual developers alike had started building apps with it (some early adopters include Slack, GitKraken, and WebTorrent), and the project was aptly renamed to Electron.

From then on, Electron hit the ground running and never stopped. Here’s a look at our weekly download count over time, courtesy of npmtrends.com:

Electron weekly downloads graph over time

Electron v1 was released in 2016, promising increased API stability and better docs and tooling. Electron v2 was released in 2018 and introduced semantic versioning, making it easier for Electron developers to keep track of the release cycle.

By Electron v6, we shifted to a regular 12-week major release cadence to match Chromium’s. This decision was a change in mentality for the project, bringing “having the most up-to-date Chromium version” from a nice-to-have to a priority. This has reduced the amount of tech debt between upgrades, making it easier for us to keep Electron updated and secure.

Since then, we’ve been a well-oiled machine, releasing a new Electron version on the same day as every Chromium stable. By the time Chromium sped up their release schedule to 4 weeks in 2021, we were able to shrug our shoulders and increase our release cadence to 8 weeks accordingly.

We’re now on Electron v23 (and counting), and are still dedicated to building the best runtime for building cross-platform desktop applications. Even with the boom in JavaScript developer tools in recent years, Electron has remained a stable, battle-tested stalwart of the desktop app framework landscape. Electron apps are ubiquitous nowadays: you can program with Visual Studio Code, design with Figma, communicate with Slack, and take notes with Notion (amongst many other use cases). We’re incredibly proud of this achievement and grateful to everyone who has made it possible.

What did we learn along the way?

The road to the decade mark has been long and winding. Here are some key things that have helped us run a sustainable large open source project.

Scaling distributed decision-making with a governance model

One challenge we had to overcome was handling the long-term direction of the project once Electron first exploded in popularity. How do we handle being a team of a couple dozen engineers distributed across companies, countries, and time zones?

In the early days, Electron’s maintainer group relied on informal coordination, which is fast and lightweight for smaller projects, but doesn’t scale to wider collaboration. In 2019, we shifted to a governance model where different working groups have formal areas of responsibility. This has been instrumental in streamlining processes and assigning portions of project ownership to specific maintainers. What is each Working Group (WG) responsible for nowadays?

  • Getting Electron releases out the door (Releases WG)
  • Upgrading Chromium and Node.js (Upgrades WG)
  • Overseeing public API design (API WG)
  • Keeping Electron secure (Security WG)
  • Running the website, documentation, and tooling (Ecosystem WG)
  • Community and corporate outreach (Outreach WG)
  • Community moderation (Community & Safety WG)
  • Maintaining our build infrastructure, maintainer tools, and cloud services (Infrastructure WG)

Around the same time we shifted to the governance model, we also moved Electron's ownership from GitHub to the OpenJS Foundation. Although the original core team still works at Microsoft today, they are only a part of a larger group of collaborators that form Electron governance.2

While this model isn’t perfect, it has suited us well through a global pandemic and ongoing macroeconomic headwinds. Going forward, we plan on revamping the governance charter to guide us through the second decade of Electron.

info

If you want to learn more, check out the electron/governance repository!

Community

The community part of open source is hard, especially when your Outreach team is a dozen engineers in a trench coat that says “community manager”. That said, being a large open source project means that we have a lot of users, and harnessing their energy for Electron to build a userland ecosystem is a crucial part of sustaining project health.

What have we been doing to develop our community presence?

Building virtual communities

  • In 2020, we launched our community Discord server. We previously had a section in Atom’s forum, but decided to have a more informal messaging platform to have a space for discussions between maintainers and Electron developers and for general debugging help.
  • In 2021, we established the Electron China user group with the help of @BlackHole1. This group has been instrumental in Electron growth in users from China’s booming tech scene, providing a space for them to collaborate on ideas and discuss Electron outside of our English-language spaces. We’d also like to thank cnpm for their work in supporting Electron’s nightly releases in their Chinese mirror for npm.

Participating in high-visibility open source programs

  • We have been celebrating Hacktoberfest every year since 2019. Hacktoberfest is yearly celebration of open source organized by DigitalOcean, and we get dozens of enthusiastic contributors every year looking to make their mark on open source software.
  • In 2020, we participated in the initial iteration of Google Season of Docs, where we worked with @bandantonio to rework Electron’s new user tutorial flow.
  • In 2022, we mentored a Google Summer of Code student for the first time. @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.

Automate all the things!

Today, Electron governance has about 30 active maintainers. Less than half of us are full-time contributors, which means that there’s a lot of work to go around. What’s our trick to keeping everything running smoothly? Our motto is that computers are cheap, and human time is expensive. In typical engineer fashion, we’ve developed a suite of automated support tooling to make our lives easier.

Not Goma

The core Electron codebase is a behemoth of C++ code, and build times have always been a limiting factor in how fast we can ship bug fixes and new features. In 2020, we deployed Not Goma, a custom Electron-specific backend for Google’s Goma distributed compiler service. Not Goma processes compilation requests from authorized user’s machines and distributes the process across hundreds of cores in the backend. It also caches the compilation result so that someone else compiling the same files will only need to download the pre-compiled result.

Since launching Not Goma, compilation times for maintainers have decreased from the scale of hours to minutes. A stable internet connection became the minimum requirement for contributors to compile Electron!

info

If you’re an open source contributor, you can also try Not Goma’s read-only cache, which is available by default with Electron Build Tools.

Continuous Factor Authentication

Continuous Factor Authentication (CFA) is a layer of automation around npm’s two-factor authentication (2FA) system that we combine with semantic-release to manage secure and automated releases of our various @electron/ npm packages.

While semantic-release already automates the npm package publishing process, it requires turning off two-factor authentication or passing in a secret token that bypasses this restriction.

We built CFA to deliver a time-based one-time password (TOTP) for npm 2FA to arbitrary CI jobs, allowing us to harness the automation of semantic-release while keeping the additional security of two-factor authentication.

We use CFA with a Slack integration front-end, allowing maintainers to validate package publishing from any device they have Slack on, as long as they have their TOTP generator handy.

info

If you want to try CFA out in your own projects, check out the GitHub repository or the docs! If you use CircleCI as your CI provider, we also have a handy orb to quickly scaffold a project with CFA.

Sheriff

Sheriff is an open source tool we wrote to automate the management of permissions across GitHub, Slack, and Google Workspace.

Sheriff’s key value proposition is that permission management should be a transparent process. It uses a single YAML config file that designates permissions across all the above listed services. With Sheriff, getting collaborator status on a repo or creating a new mailing list is as easy as getting a PR approved and merged.

Sheriff also has an audit log that posts to Slack, warning admins when suspicious activity occurs anywhere in the Electron organization.

…and all our GitHub bots

GitHub is a platform with rich API extensibility and a first-party bot application framework called Probot. To help us focus on the more creative parts of our job, we built out a suite of smaller bots that help do the dirty work for us. Here are a few examples:

  • Sudowoodo automates the Electron release process from start to finish, from kicking off builds to uploading the release assets to GitHub and npm.
  • Trop automates the backporting process for Electron by attempting to cherry-pick patches to previous release branches based on GitHub PR labels.
  • Roller automates rolling upgrades of Electron’s Chromium and Node.js dependencies.
  • Cation is our status check bot for electron/electron PRs.

Altogether, our little family of bots has given us a huge boost in developer productivity!

What’s next?

As we enter our second decade as a project, you might be asking: what’s next for Electron?

We’re going to stay in sync with Chromium's release cadence, releasing new major versions of Electron every 8 weeks, keeping the framework updated with the latest and greatest from the web platform and Node.js while maintaining stability and security for enterprise-grade applications.

We generally announce news on upcoming initiatives when they become concrete. If you want to keep up with future releases, features, and general project updates, you can read our blog and follow our social media profiles (Twitter and Mastodon)!

Footnotes

  1. This is actually the first commit from the electron-archive/brightray project, which got absorbed into Electron in 2017 and had its git history merged. But who’s counting? It’s our birthday, so we get to make the rules!

  2. Contrary to popular belief, Electron is no longer owned by GitHub or Microsoft, and is part of the OpenJS Foundation nowadays.

Electron 23.0.0

· 3 min read

Electron 23.0.0 has been released! It includes upgrades to Chromium 110, V8 11.0, and Node.js 18.12.1. Additionally, support for Windows 7/8/8.1 has been dropped. Read below for more details!


The Electron team is excited to announce the release of Electron 23.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 join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes

Stack Changes

New Features

  • Added label property to Display objects. #36933
  • Added an app.getPreferredSystemLanguages() API to return the user's system languages. #36035
  • Added support for the WebUSB API. #36289
  • Added support for SerialPort.forget() as well as a new event serial-port-revoked emitted on Session objects when a given origin is revoked. #35310
  • Added new win.setHiddenInMissionControl API to allow developers to opt out of Mission Control on macOS. #36092

Dropping Windows 7/8/8.1 Support

Electron 23 no longer supports Windows 7/8/8.1. Electron follows the planned Chromium deprecation policy, which will deprecate Windows 7/8/8.1 , as well as Windows Server 2012 and 2012 R2 support in Chromium 109 (read more here).

Breaking API Changes

Below are breaking changes introduced in Electron 23. You can read more about these changes and future changes on the Planned Breaking Changes page.

Removed: BrowserWindow scroll-touch-* events

The deprecated scroll-touch-begin, scroll-touch-end and scroll-touch-edge events on BrowserWindow have been removed. Instead, use the newly available input-event event on WebContents.

// Removed in Electron 23.0
-win.on('scroll-touch-begin', scrollTouchBegin)
-win.on('scroll-touch-edge', scrollTouchEdge)
-win.on('scroll-touch-end', scrollTouchEnd)

// Replace with
+win.webContents.on('input-event', (_, event) => {
+ if (event.type === 'gestureScrollBegin') {
+ scrollTouchBegin()
+ } else if (event.type === 'gestureScrollUpdate') +{
+ scrollTouchEdge()
+ } else if (event.type === 'gestureScrollEnd') {
+ scrollTouchEnd()
+ }
+})

End of Support for 20.x.y

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

E22 (Nov'22)E23 (Feb'23)E24 (Apr'23)E25 (May'23)E26 (Aug'23)
22.x.y23.x.y24.x.y25.x.y26.x.y
21.x.y22.x.y23.x.y24.x.y25.x.y
20.x.y21.x.y22.x.y23.x.y24.x.y

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.

You can find Electron's public timeline here.

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

Electron 22.0.0

· 5 min read

Electron 22.0.0 has been released! It includes a new utility process API, updates for Windows 7/8/8.1 support, and upgrades to Chromium 108, V8 10.8, and Node.js 16.17.1. Read below for more details!


The Electron team is excited to announce the release of Electron 22.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 join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes

Stack Changes

Highlighted Features

UtilityProcess API #36089

The new UtilityProcess main process module allows the creation of a lightweight Chromium child process with only Node.js integration while also allowing communication with a sandboxed renderer using MessageChannel. The API was designed based on Node.js child_process.fork to allow for easier transition, with one primary difference being that the entry point modulePath must be from within the packaged application to allow only for trusted scripts to be loaded. Additionally the module prevents establishing communication channels with renderers by default, upholding the contract in which the main process is the only trusted process in the application.

You can read more about the new UtilityProcess API in our docs here.

Windows 7/8/8.1 Support Update

info

2023/02/16: An update on Windows Server 2012 support

Last month, Google announced that Chrome 109 would continue to receive critical security fixes for Windows Server 2012 and Windows Server 2012 R2 until October 10, 2023. In accordance, Electron 22's (Chromium 108) planned end of life date will be extended from May 30, 2023 to October 10, 2023. The Electron team will continue to backport any security fixes that are part of this program to Electron 22 until October 10, 2023.

Note that we will not make additional security fixes for Windows 7/8/8.1. Also, Electron 23 (Chromium 110) will only function on Windows 10 and above as previously announced.

Electron 22 will be the last Electron major version to support Windows 7/8/8.1. Electron follows the planned Chromium deprecation policy, which will deprecate Windows 7/8/8.1 support in Chromium 109 (read more here).

Windows 7/8/8.1 will not be supported in Electron 23 and later major releases.

Additional Highlighted Changes

  • Added support for Web Bluetooth pin pairing on Linux and Windows. #35416
  • Added LoadBrowserProcessSpecificV8Snapshot as a new fuse that will let the main/browser process load its v8 snapshot from a file at browser_v8_context_snapshot.bin. Any other process will use the same path as is used today. #35266
  • Added WebContents.opener to access window opener and webContents.fromFrame(frame) to get the WebContents corresponding to a WebFrameMain instance. #35140
  • Added support for navigator.mediaDevices.getDisplayMedia via a new session handler, ses.setDisplayMediaRequestHandler. #30702

Breaking API Changes

Below are breaking changes introduced in Electron 22. You can read more about these changes and future changes on the Planned Breaking Changes page.

Deprecated: webContents.incrementCapturerCount(stayHidden, stayAwake)

webContents.incrementCapturerCount(stayHidden, stayAwake) has been deprecated. It is now automatically handled by webContents.capturePage when a page capture completes.

const w = new BrowserWindow({ show: false })

- w.webContents.incrementCapturerCount()
- w.capturePage().then(image => {
- console.log(image.toDataURL())
- w.webContents.decrementCapturerCount()
- })

+ w.capturePage().then(image => {
+ console.log(image.toDataURL())
+ })

Deprecated: webContents.decrementCapturerCount(stayHidden, stayAwake)

webContents.decrementCapturerCount(stayHidden, stayAwake) has been deprecated. It is now automatically handled by webContents.capturePage when a page capture completes.

const w = new BrowserWindow({ show: false })

- w.webContents.incrementCapturerCount()
- w.capturePage().then(image => {
- console.log(image.toDataURL())
- w.webContents.decrementCapturerCount()
- })

+ w.capturePage().then(image => {
+ console.log(image.toDataURL())
+ })

Removed: WebContents new-window event

The new-window event of WebContents has been removed. It is replaced by webContents.setWindowOpenHandler().

- webContents.on('new-window', (event) => {
- event.preventDefault()
- })

+ webContents.setWindowOpenHandler((details) => {
+ return { action: 'deny' }
+ })

Deprecated: BrowserWindow scroll-touch-* events

The scroll-touch-begin, scroll-touch-end and scroll-touch-edge events on BrowserWindow are deprecated. Instead, use the newly available input-event event on WebContents.

// Deprecated
- win.on('scroll-touch-begin', scrollTouchBegin)
- win.on('scroll-touch-edge', scrollTouchEdge)
- win.on('scroll-touch-end', scrollTouchEnd)

// Replace with
+ win.webContents.on('input-event', (_, event) => {
+ if (event.type === 'gestureScrollBegin') {
+ scrollTouchBegin()
+ } else if (event.type === 'gestureScrollUpdate') {
+ scrollTouchEdge()
+ } else if (event.type === 'gestureScrollEnd') {
+ scrollTouchEnd()
+ }
+ })

End of Support for 19.x.y

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

E19 (May'22)E20 (Aug'22)E21 (Sep'22)E22 (Nov'22)E23 (Jan'23)
19.x.y20.x.y21.x.y22.x.y23.x.y
18.x.y19.x.y20.x.y21.x.y22.x.y
17.x.y18.x.y19.x.y20.x.y21.x.y

What's Next

The Electron project will pause for the the month of December 2022, and return in January 2023. More information can be found in the December shutdown blog post.

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.

Farewell, Windows 7/8/8.1

· 3 min read

Electron will end support of Windows 7, Windows 8 and Windows 8.1 beginning in Electron 23.


In line with Chromium’s deprecation policy, Electron will end support of Windows 7, Windows 8 and Windows 8.1 beginning in Electron 23. This matches Microsoft's end of support for Windows 7 ESU and Windows 8.1 extended on January 10th, 2023.

Electron 22 will be the last Electron major version to support Windows versions older than 10. Windows 7/8/8.1 will not be supported in Electron 23 and later major releases. Older versions of Electron will continue to function on Windows 7, and we will continue to release patches for Electron the 22.x series until May 30 2023, when Electron will end support for 22.x (according to our support timeline).

Why deprecate?

Electron follows the planned Chromium deprecation policy, which will deprecate support in Chromium 109 (read more about Chromium's timeline here). Electron 23 will contain Chromium 110, which won’t support older versions of Windows.

Electron 22, which contains Chromium 108, will thus be the last supported version.

Deprecation timeline

The following is our planned deprecation timeline:

  • December 2022: The Electron team is entering a quiet period for the holidays
  • January 2023: Windows 7 & 8 related issues are accepted for all supported release branches.
  • February 7 2023: Electron 23 is released.
  • February 8 2023 - May 29 2023: Electron will continue to accept fixes for supported lines older than Electron 23.
  • May 30 2023: Electron 22 reaches the end of its support cycle.

What this means for developers:

  • The Electron team will accept issues and fixes related to Windows 7/8/8.1 for stable supported lines, until each line reaches the end of its support cycle.
    • This specifically applies to Electron 22, Electron 21 and Electron 20.
  • New issues related to Windows 7/8/8.1 will be accepted for Electron versions older than Electron 23.
    • New issues will not be accepted for any newer release lines.
  • Once Electron 22 has reached the end of its support cycle, all existing issues related to Windows 7/8/8.1 will be closed.
info

2023/02/16: An update on Windows Server 2012 support

Last month, Google announced that Chrome 109 would continue to receive critical security fixes for Windows Server 2012 and Windows Server 2012 R2 until October 10, 2023. In accordance, Electron 22's (Chromium 108) planned end of life date will be extended from May 30, 2023 to October 10, 2023. The Electron team will continue to backport any security fixes that are part of this program to Electron 22 until October 10, 2023.

Note that we will not make additional security fixes for Windows 7/8/8.1. Also, Electron 23 (Chromium 110) will only function on Windows 10 and above as previously announced.

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.