Skip to main content

Discontinuing support for 32-bit Linux

· 3 min read

The Electron team will discontinue support for 32-bit Linux (ia32 / i386) starting with Electron v4.0. The last version of Electron that supports 32-bit based installations of Linux is Electron v3.1, which will receive support releases until Electron v6 is released. Support for 64-bit based Linux and armv7l will continue unchanged.


What exactly is Electron no longer supporting?

You may have seen the description "64-bit" and "32-bit" as stickers on your computer or as options for downloading software. The term is used to describe a specific computer architecture. Most computers made in the 1990s and early 2000s were made with CPUs that were based on the 32-bit architecture, while most computers made later were based on the newer and more powerful 64-bit architecture. The Nintendo 64 (get it?) and the PlayStation 2 were the first widely available consumer devices with the new architecture, computers sold after 2010 contained almost exclusively 64-bit processors. As a result, support has been shrinking: Google stopped releasing Chrome for 32-bit Linux in March 2016, Canonical stopped providing 32-bit desktop images in 2017 and dropped support for 32-bit altogether with Ubuntu 18.10. Arch Linux, elementary OS, and other prominent Linux distributions have already dropped support for the aging processor architecture.

Until now, Electron has provided and supported builds that run on the older 32-bit architecture. From release v4.0 onwards, the Electron team will no longer be able to provide binaries or support for 32-bit Linux.

Electron has always been a vibrant open source project and we continue to support and encourage developers interested in building Electron for exotic architectures.

What does that mean for developers?

If you are not currently providing 32-bit distributions of your app for Linux, no action is required.

Projects which ship 32-bit Linux Electron applications will need to decide how to proceed. 32-bit Linux will be supported on Electron 3 until the release of Electron 6, which gives some time to make decisions and plans.

What does that mean for users?

If you are a Linux user and not sure whether or not you're running a 64-bit based system, you are likely running on a 64-bit based architecture. To make sure, you can run the lscpu or uname -m commands in your terminal. Either one will print your current architecture.

If you are using Linux on a 32-bit processor, you have likely already encountered difficulties finding recently released software for your operating system. The Electron team joins other prominent members in the Linux community by recommending that you upgrade to a 64-bit based architecture.

BrowserView window.open() Vulnerability Fix

· One min read

A code vulnerability has been discovered that allows Node to be re-enabled in child windows.


Opening a BrowserView with sandbox: true or nativeWindowOpen: true and nodeIntegration: false results in a webContents where window.open can be called and the newly opened child window will have nodeIntegration enabled. This vulnerability affects all supported versions of Electron.

Mitigation

We've published new versions of Electron which include fixes for this vulnerability: 2.0.17, 3.0.15, 3.1.3, 4.0.4, and 5.0.0-beta.2. We encourage all Electron developers to update their apps to the latest stable version immediately.

If for some reason you are unable to upgrade your Electron version, you can mitigate this issue by disabling all child web contents:

view.webContents.on('-add-new-contents', (e) => e.preventDefault());

Further Information

This vulnerability was found and reported responsibly to the Electron project by PalmerAL.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

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

Node.js Native Addons and Electron 5.0

· 2 min read

If you're having trouble using a native Node.js addon with Electron 5.0, there's a chance it needs to be updated to work with the most recent version of V8.


Goodbye v8::Handle, Hello v8::Local

In 2014, the V8 team deprecated v8::Handle in favor of v8::Local for local handles. Electron 5.0 includes a version of V8 that has finally removed v8::Handle for good, and native Node.js addons that still use it will need to be updated before they can be used with Electron 5.0.

The required code change is minimal, but every native Node module that still uses v8::Handle will fail to build with Electron 5.0 and will need to be modified. The good news is that Node.js v12 will also include this V8 change, so any modules that use v8::Handle will need to be updated anyway to work with the upcoming version of Node.

I maintain a native addon, how can I help?

If you maintain a native addon for Node.js, ensure you replace all occurrences of v8::Handle with v8::Local. The former was just an alias of the latter, so no other changes need to be made to address this specific issue.

You may also be interested in looking into N-API, which is maintained separately from V8 as a part of Node.js itself, and aims to insulate native addons from changes in the underlying JavaScript engine. You can find more information in the N-API documentation on the Node.js website.

Help! I use a native addon in my app and it won't work!

If you're consuming a native addon for Node.js in your app and the native addon will not build because of this issue, check with the author of the addon to see if they've released a new version that fixes the problem. If not, reaching out to the author (or opening a Pull Request!) is probably your best bet.

Electron v5.0.0 Timeline

· 2 min read

For the first time ever, Electron is excited to publicize our release schedule starting with v5.0.0. This is our first step in having a public, long-term timeline.


As mentioned in our v4.0.0 stable release blog post, we are planning to release approximately quarterly to maintain closer cadence with Chromium releases. Chromium releases a new version very quickly -- every 6 weeks.

Take a look at progression in Electron versus Chromium side-by-side:

line graph comparing Electron versus Chromium versions

In the last half of 2018, our top priority was releasing faster and catching up closer to Chromium. We succeeded by sticking to a predetermined timeline. Electron 3.0.0 and 4.0.0 were released in a 2-3 month timeline for each release. We are optimistic about continuing that pace in releasing 5.0.0 and beyond. With a major Electron release approximately every quarter, we're now keeping pace with Chromium's release cadence. Getting ahead of Chromium stable release is always a goal for us and we are taking steps towards that.

We would love to promise future dates like Node.js and Chromium do, but we are not at that place yet. We are optimistic that we will reach a long-term timeline in the future.

With that in mind, we are taking first steps by publicly posting our release schedule for v5.0.0. You can find that here.

To help us with testing our beta releases and stabilization, please consider joining our App Feedback Program.

Electron 4.0.0

· 6 min read

The Electron team is excited to announce that the stable release of Electron 4 is now available! You can install it from electronjs.org or from npm via npm install electron@latest. The release is packed with upgrades, fixes, and new features, and we can't wait to see what you build with them. Read more for details about this release, and please share any feedback you have as you explore!


What's New?

A large part of Electron's functionality is provided by Chromium, Node.js, and V8, the core components that make up Electron. As such, a key goal for the Electron team is to keep up with changes to these projects as much as possible, providing developers who build Electron apps access to new web and JavaScript features. To this end, Electron 4 features major version bumps to each of these components; Electron v4.0.0 includes Chromium 69.0.3497.106, Node 10.11.0, and V8 6.9.427.24.

In addition, Electron 4 includes changes to Electron-specific APIs. You can find a summary of the major changes in Electron 4 below; for the full list of changes, check out the Electron v4.0.0 release notes.

Disabling the remote Module

You now have the ability to disable the remote module for security reasons. The module can be disabled for BrowserWindows and for webview tags:

// BrowserWindow
new BrowserWindow({
webPreferences: {
enableRemoteModule: false
}
})

// webview tag
<webview src="http://www.google.com/" enableremotemodule="false"></webview>

See the BrowserWindow and <webview> Tag documentation for more information.

Filtering remote.require() / remote.getGlobal() Requests

This feature is useful if you don't want to completely disable the remote module in your renderer process or webview but would like additional control over which modules can be required via remote.require.

When a module is required via remote.require in a renderer process, a remote-require event is raised on the app module. You can call event.preventDefault() on the the event (the first argument) to prevent the module from being loaded. The WebContents instance where the require occurred is passed as the second argument, and the name of the module is passed as the third argument. The same event is also emitted on the WebContents instance, but in this case the only arguments are the event and the module name. In both cases, you can return a custom value by setting the value of event.returnValue.

// Control `remote.require` from all WebContents:
app.on('remote-require', function (event, webContents, requestedModuleName) {
// ...
});

// Control `remote.require` from a specific WebContents instance:
browserWin.webContents.on(
'remote-require',
function (event, requestedModuleName) {
// ...
}
);

In a similar fashion, when remote.getGlobal(name) is called, a remote-get-global event is raised. This works the same way as the remote-require event: call preventDefault() to prevent the global from being returned, and set event.returnValue to return a custom value.

// Control `remote.getGlobal` from all WebContents:
app.on(
'remote-get-global',
function (event, webContents, requrestedGlobalName) {
// ...
}
);

// Control `remote.getGlobal` from a specific WebContents instance:
browserWin.webContents.on(
'remote-get-global',
function (event, requestedGlobalName) {
// ...
}
);

For more information, see the following documentation:

JavaScript Access to the About Panel

On macOS, you can now call app.showAboutPanel() to programmatically show the About panel, just like clicking the menu item created via {role: 'about'}. See the showAboutPanel documentation for more information

Controlling WebContents Background Throttling

WebContents instances now have a method setBackgroundThrottling(allowed) to enable or disable throttling of timers and animations when the page is backgrounded.

let win = new BrowserWindow(...)
win.webContents.setBackgroundThrottling(enableBackgroundThrottling)

See the setBackgroundThrottling documentation for more information.

Breaking Changes

No More macOS 10.9 Support

Chromium no longer supports macOS 10.9 (OS X Mavericks), and as a result Electron 4.0 and beyond does not support it either.

Single Instance Locking

Previously, to make your app a Single Instance Application (ensuring that only one instance of your app is running at any given time), you could use the app.makeSingleInstance() method. Starting in Electron 4.0, you must use app.requestSingleInstanceLock() instead. The return value of this method indicates whether or not this instance of your application successfully obtained the lock. If it failed to obtain the lock, you can assume that another instance of your application is already running with the lock and exit immediately.

For an example of using requestSingleInstanceLock() and information on nuanced behavior on various platforms, see the documentation for app.requestSingleInstanceLock() and related methods and the second-instance event.

win_delay_load_hook

When building native modules for windows, the win_delay_load_hook variable in the module's binding.gyp must be true (which is the default). If this hook is not present, then the native module will fail to load on Windows, with an error message like Cannot find module. See the native module guide for more information.

Deprecations

The following breaking changes are planned for Electron 5.0, and thus are deprecated in Electron 4.0.

Node.js Integration Disabled for nativeWindowOpen-ed Windows

Starting in Electron 5.0, child windows opened with the nativeWindowOpen option will always have Node.js integration disabled.

webPreferences Default Values

When creating a new BrowserWindow with the webPreferences option set, the following webPreferences option defaults are deprecated in favor of new defaults listed below:

PropertyDeprecated DefaultNew Default
contextIsolationfalsetrue
nodeIntegrationtruefalse
webviewTagvalue of nodeIntegration if set, otherwise truefalse

Please note: there is currently a known bug (#9736) that prevents the webview tag from working if contextIsolation is on. Keep an eye on the GitHub issue for up-to-date information!

Learn more about context isolation, Node integration, and the webview tag in the Electron security document.

Electron 4.0 will still use the current defaults, but if you don't pass an explicit value for them, you'll see a deprecation warning. To prepare your app for Electron 5.0, use explicit values for these options. See the BrowserWindow docs for details on each of these options.

webContents.findInPage(text[, options])

The medialCapitalAsWordStart and wordStart options have been deprecated as they have been removed upstream.

App Feedback Program

The App Feedback Program we instituted during the development of Electron 3.0 was successful, so we've continued it during the development of 4.0 as well. We'd like to extend a massive thank you to Atlassian, Discord, MS Teams, OpenFin, Slack, Symphony, WhatsApp, and the other program members for their involvement during the 4.0 beta cycle. To learn more about the App Feedback Program and to participate in future betas, 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. 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.

SQLite Vulnerability Fix

· One min read

A remote code execution vulnerability, "Magellan," has been discovered affecting software based on SQLite or Chromium, including all versions of Electron.


Scope

Electron applications using Web SQL are impacted.

Mitigation

Affected apps should stop using Web SQL or upgrade to a patched version of Electron.

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

There are no reports of this in the wild; however, affected applications are urged to mitigate.

Further Information

This vulnerability was discovered by the Tencent Blade team, who have published a blog post that discusses the vulnerability.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

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

Electron App Feedback Program

· 3 min read

Electron is working on making its release cycles faster and more stable. To make that possible, we've started the App Feedback Program for large-scale Electron apps to test our beta releases and report app-specific issues to us. This helps us to prioritize work that will get applications upgraded to our next stable release sooner.

Edit (2020-05-21): This program has been retired.


Who can join?

Our criteria and expectations for apps joining this program include the following items:

  • Test your app during the beta period for 10,000+ user-hours
  • Have a single point-person who will check in weekly to discuss your app's Electron bugs and app blockers
  • You agree to abide by Electron's Code of Conduct
  • You are willing to share the following information listed in the next question

What info does my Electron app have to share?

  • Total user-hours your app has been running with any beta release
  • Version of Electron that your app is testing with (e.g., 4.0.0-beta.3)
  • Any bugs preventing your application from upgrading to the release line being beta tested

User-hours

We understand not everyone can share exact user numbers, however better data helps us decide how stable a particular release is. We ask that apps commit to testing a minimum number of user-hours, currently 10,000 across the beta cycle.

  • 10 user-hours could be 10 people testing for one hour, or one person testing for 10 hours
  • You can split the testing between beta releases, for example test for 5,000 user-hours on 3.0.0-beta.2 and then test for 5,000 user-hours on 3.0.0-beta.5. More is better, but we understand that some applications cannot test every beta release
  • CI or QA hours do not count towards the total; however, internal releases do count

Why should my Electron app join?

Your app's bugs will be tracked and be on the core Electron team's radar. Your feedback helps the Electron team to see how the new betas are doing and what work needs to be done.

Will my application's info be shared publicly? Who gets to see this info?

No, your application's information will not be shared with the general public. Information is kept in a private GitHub repo that is only viewable to members of the App Feedback Program and Electron Governance. All members have agreed to follow Electron's Code of Conduct.

Sign up

We are currently accepting a limited number of signups. If you are interested and are able to fulfill the above requirements, please fill out this form.

Electron 3.0.0

· 4 min read

The Electron team is excited to announce that the first stable release of Electron 3 is now available from electronjs.org and via npm install electron@latest! It's jam-packed with upgrades, fixes, and new features, and we can't wait to see what you build with them. Below are details about this release, and we welcome your feedback as you explore.


Release Process

As we undertook development of v3.0.0, we sought to more empirically define criteria for a stable release by formalizing the feedback progress for progressive beta releases. v3.0.0 would not have been possible without our App Feedback Program partners, who provided early testing and feedback during the beta cycle. Thanks to Atlassian, Atom, Microsoft Teams, Oculus, OpenFin, Slack, Symphony, VS Code, and other program members for their work. If you'd like to participate in future betas, please mail us at info@electronjs.org.

Changes / New Features

Major bumps to several important parts of Electron's toolchain, including Chrome v66.0.3359.181, Node v10.2.0, and V8 v6.6.346.23.

  • [#12656] feat: app.isPackaged
  • [#12652] feat: app.whenReady()
  • [#13183] feat: process.getHeapStatistics()
  • [#12485] feat: win.moveTop() to move window z-order to top
  • [#13110] feat: TextField and Button APIs
  • [#13068] feat: netLog API for dynamic logging control
  • [#13539] feat: enable webview in sandbox renderer
  • [#14118] feat: fs.readSync now works with massive files
  • [#14031] feat: node fs wrappers to make fs.realpathSync.native and fs.realpath.native available

Breaking API changes

  • [#12362] feat: updates to menu item order control
  • [#13050] refactor: removed documented deprecated APIs
    • See docs for more details
  • [#12477] refactor: removed did-get-response-details and did-get-redirect-request events
  • [#12655] feat: default to disabling navigating on drag/drop
  • [#12993] feat: Node v4.x or greater is required use the electron npm module
  • [#12008 #12140 #12503 #12514 #12584 #12596 #12637 #12660 #12696 #12716 #12750 #12787 #12858] refactor: NativeWindow
  • [#11968] refactor: menu.popup()
  • [#8953] feat: no longer use JSON to send the result of ipcRenderer.sendSync
  • [#13039] feat: default to ignore command line arguments following a URL
  • [#12004] refactor: rename api::Window to api::BrowserWindow
  • [#12679] feat: visual zoom now turned off by default
  • [#12408] refactor: rename app-command media-play_pause to media-play-pause

macOS

  • [#12093] feat: workspace notifications support
  • [#12496] feat: tray.setIgnoreDoubleClickEvents(ignore) to ignore tray double click events.
  • [#12281] feat: mouse forward functionality on macOS
  • [#12714] feat: screen lock / unlock events

Windows

  • [#12879] feat: added DIP to/from screen coordinate conversions

Nota Bene: Switching to an older version of Electron after running this version will require you to clear out your user data directory to avoid older versions crashing. You can get the user data directory by running console.log(app.getPath("userData")) or see docs for more details.

Bug Fixes

  • [#13397] fix: issue with fs.statSyncNoException throwing exceptions
  • [#13476, #13452] fix: crash when loading site with jquery
  • [#14092] fix: crash in net::ClientSocketHandle destructor
  • [#14453] fix: notify focus change right away rather not on next tick

MacOS

  • [#13220] fix: issue allowing bundles to be selected in <input file="type"> open file dialog
  • [#12404] fix: issue blocking main process when using async dialog
  • [#12043] fix: context menu click callback
  • [#12527] fix: event leak on reuse of touchbar item
  • [#12352] fix: tray title crash
  • [#12327] fix: non-draggable regions
  • [#12809] fix: to prevent menu update while it's open
  • [#13162] fix: tray icon bounds not allowing negative values
  • [#13085] fix: tray title not inverting when highlighted
  • [#12196] fix: Mac build when enable_run_as_node==false
  • [#12157] fix: additional issues on frameless windows with vibrancy
  • [#13326] fix: to set mac protocol to none after calling app.removeAsDefaultProtocolClient
  • [#13530] fix: incorrect usage of private APIs in MAS build
  • [#13517] fix: tray.setContextMenu crash
  • [#14205] fix: pressing escape on a dialog now closes it even if defaultId is set

Linux

  • [#12507] fix: BrowserWindow.focus() for offscreen windows

Other Notes

  • PDF Viewer is currently not working but is being worked on and will be functional once again soon
  • TextField and Button APIs are experimental and are therefore off by default
    • They can be enabled with the enable_view_api build flag

What's Next

The Electron team continues to work on defining our processes for more rapid and smooth upgrades as we seek to ultimately maintain parity with the development cadences of Chromium, Node, and V8.

Using GN to Build Electron

· 2 min read

Electron now uses GN to build itself. Here's a discussion of why.


GYP and GN

When Electron was first released in 2013, Chromium's build configuration was written with GYP, short for "Generate Your Projects".

In 2014, the Chromium project introduced a new build configuration tool called GN (short for "Generate Ninja") Chromium's build files were migrated to GN and GYP was removed from the source code.

Electron has historically kept a separation between the main Electron code and libchromiumcontent, the part of Electron that wraps Chromium's 'content' submodule. Electron has carried on using GYP, while libchromiumcontent -- as a subset of Chromium -- switched to GN when Chromium did.

Like gears that don't quite mesh, there was friction between using the two build systems. Maintaining compatibility was error-prone, from compiler flags and #defines that needed to be meticulously kept in sync between Chromium, Node, V8, and Electron.

To address this, the Electron team has been working on moving everything to GN. Today, the commit to remove the last of the GYP code from Electron was landed in master.

What this means for you

If you're contributing to Electron itself, the process of checking out and building Electron from master or 4.0.0 is very different than it was in 3.0.0 and earlier. See the GN build instructions for details.

If you're developing an app with Electron, there are a few minor changes you might notice in the new Electron 4.0.0-nightly; but more than likely, Electron's change in build system will be totally transparent to you.

What this means for Electron

GN is faster than GYP and its files are more readable and maintainable. Moreover, we hope that using a single build configuration system will reduce the work required to upgrade Electron to new versions of Chromium.

  • It's already helped development on Electron 4.0.0 substantially because Chromium 67 removed support for MSVC and switched to building with Clang on Windows. With the GN build, we inherit all the compiler commands from Chromium directly, so we got the Clang build on Windows for free!

  • It's also made it easier for Electron to use BoringSSL in a unified build across Electron, Chromium, and Node -- something that was problematic before.

WebPreferences Vulnerability Fix

· 2 min read

A remote code execution vulnerability has been discovered affecting apps with the ability to open nested child windows on Electron versions (3.0.0-beta.6, 2.0.7, 1.8.7, and 1.7.15). This vulnerability has been assigned the CVE identifier CVE-2018-15685.


Affected Platforms

You are impacted if:

  1. You embed any remote user content, even in a sandbox
  2. You accept user input with any XSS vulnerabilities

Details

You are impacted if any user code runs inside an iframe / can create an iframe. Given the possibility of an XSS vulnerability it can be assumed that most apps are vulnerable to this case.

You are also impacted if you open any of your windows with the nativeWindowOpen: true or sandbox: true option. Although this vulnerability also requires an XSS vulnerability to exist in your app, you should still apply one of the mitigations below if you use either of these options.

Mitigation

We've published new versions of Electron which include fixes for this vulnerability: 3.0.0-beta.7, 2.0.8, 1.8.8, and 1.7.16. We urge all Electron developers to update their apps to the latest stable version immediately.

If for some reason you are unable to upgrade your Electron version, you can protect your app by blanket-calling event.preventDefault() on the new-window event for all webContents'. If you don't use window.open or any child windows at all then this is also a valid mitigation for your app.

mainWindow.webContents.on('new-window', (e) => e.preventDefault());

If you rely on the ability of your child windows to make grandchild windows, then a third mitigation strategy is to use the following code on your top level window:

const enforceInheritance = (topWebContents) => {
const handle = (webContents) => {
webContents.on(
'new-window',
(event, url, frameName, disposition, options) => {
if (!options.webPreferences) {
options.webPreferences = {};
}
Object.assign(
options.webPreferences,
topWebContents.getLastWebPreferences()
);
if (options.webContents) {
handle(options.webContents);
}
}
);
};
handle(topWebContents);
};

enforceInheritance(mainWindow.webContents);

This code will manually enforce that the top level windows webPreferences is manually applied to all child windows infinitely deep.

Further Information

This vulnerability was found and reported responsibly to the Electron project by Matt Austin of Contrast Security.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

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