Ir para o conteúdo principal

· Leitura de 3 minutos

Electron 21.0.0 has been released! It includes upgrades to Chromium 106, V8 10.6, and Node.js 16.16.0. Read below for more details!


The Electron team is excited to announce the release of Electron 21.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 webFrameMain.origin. #35534
  • Added new WebContents.ipc and WebFrameMain.ipc APIs. #35231
  • Added support for panel-like behavior. Window can float over full-screened apps. #34388
  • Added support for push notifications from APNs for macOS apps. #33574

Breaking & API Changes

Below are breaking changes introduced in Electron 21.

V8 Memory Cage Enabled

Electron 21 enables V8 sandboxed pointers, following Chrome's decision to do the same in Chrome 103. This has some implications for native modules. This feature has performance and security benefits, but also places some new restrictions on native modules, e.g. use of ArrayBuffers that point to external ("off-heap") memory. Please see this blog post for more information. #34724

Refactored webContents.printToPDF

Refactored webContents.printToPDF to align with Chromium's headless implementation. See #33654 for more information.

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

End of Support for 18.x.y

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

E18 (Mar'22)E19 (May'22)E20 (Aug'22)E21 (Sep'22)E22 (Dec'22)
18.x.y19.x.y20.x.y21.x.y22.x.y
17.x.y18.x.y19.x.y20.x.y21.x.y
16.x.y17.x.y18.x.y19.x.y20.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.

· Leitura de 4 minutos

Electron 20.0.0 has been released! It includes upgrades to Chromium 104, V8 10.4, and Node.js 16.15.0. Read below for more details!


The Electron team is excited to announce the release of Electron 20.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 and please share any feedback you have!

Notable Changes

New Features

  • Added immersive dark mode on Windows. #34549
  • Added support for panel-like behavior. Window can float over full-screened apps. #34665
  • Updated Windows Control Overlay buttons to look and feel more native on Windows 11. #34888
  • Renderers are now sandboxed by default unless nodeIntegration: true or sandbox: false is specified. #35125
  • Added safeguards when building native modules with nan. #35160

Stack Changes

Breaking & API Changes

Below are breaking changes introduced in Electron 20. More information about these and future changes can be found on the Planned Breaking Changes page.

Default Changed: renderers without nodeIntegration: true are sandboxed by default

Previously, renderers that specified a preload script defaulted to being unsandboxed. This meant that by default, preload scripts had access to Node.js. In Electron 20, this default has changed. Beginning in Electron 20, renderers will be sandboxed by default, unless nodeIntegration: true or sandbox: false is specified.

If your preload scripts do not depend on Node, no action is needed. If your preload scripts do depend on Node, either refactor them to remove Node usage from the renderer, or explicitly specify sandbox: false for the relevant renderers.

Fixed: spontaneous crashing in nan native modules

In Electron 20, we changed two items related to native modules:

  1. V8 headers now use c++17 by default. This flag was added to electron-rebuild.
  2. We fixed an issue where a missing include would cause spontaneous crashing in native modules that depended on nan.

For the most stability, we recommend using node-gyp >=8.4.0 and electron-rebuild >=3.2.9 when rebuilding native modules, particularly modules that depend on nan. See electron #35160 and node-gyp #2497 for more information.

Removed: .skipTaskbar on Linux

On X11, skipTaskbar sends a _NET_WM_STATE_SKIP_TASKBAR message to the X11 window manager. There is not a direct equivalent for Wayland, and the known workarounds have unacceptable tradeoffs (e.g. Window.is_skip_taskbar in GNOME requires unsafe mode), so Electron is unable to support this feature on Linux.

End of Support for 17.x.y

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

E18 (Mar'22)E19 (May'22)E20 (Aug'22)E21 (Sep'22)E22 (Dec'22)
18.x.y19.x.y20.x.y21.x.y22.x.y
17.x.y18.x.y19.x.y20.x.y21.x.y
16.x.y17.x.y18.x.y19.x.y20.x.y
15.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. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately every 2 months.

You can find Electron's public timeline here.

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

· Leitura de 7 minutos

Electron 21 and later will have the V8 Memory Cage enabled, with implications for some native modules.


In Electron 21, we will be enabling V8 sandboxed pointers in Electron, following Chrome's decision to do the same in Chrome 103. This has some implications for native modules. Also, we previously enabled a related technology, pointer compression, in Electron 14. We didn't talk about it much then, but pointer compression has implications for the maximum V8 heap size.

These two technologies, when enabled, are significantly beneficial for security, performance and memory usage. However, there are some downsides to enabling them, too.

The main downside of enabling sandboxed pointers is that ArrayBuffers which point to external ("off-heap") memory are no longer allowed. This means that native modules which rely on this functionality in V8 will need to be refactored to continue working in Electron 20 and later.

The main downside of enabling pointer compression is that the V8 heap is limited to a maximum size of 4GB. The exact details of this are a little complicated—for example, ArrayBuffers are counted separately from the rest of the V8 heap, but have their own limits.

The Electron Upgrades Working Group believes that the benefits of pointer compression and the V8 memory cage outweigh the downsides. There are three main reasons for doing so:

  1. It keeps Electron closer to Chromium. The less Electron diverges from Chromium in complex internal details such as V8 configuration, the less likely we are to accidentally introduce bugs or security vulnerabilities. Chromium's security team is formidable, and we want to make sure we are taking advantage of their work. Further, if a bug only affects configurations that aren't used in Chromium, fixing it is not likely to be a priority for the Chromium team.
  2. It performs better. Pointer compression reduces V8 heap size by up to 40% and improves CPU and GC performance by 5%–10%. For the vast majority of Electron applications which won't bump into the 4GB heap size limit and don't use native modules that require external buffers, these are significant performance wins.
  3. It's more secure. Some Electron apps run untrusted JavaScript (hopefully following our security recommendations!), and for those apps, having the V8 memory cage enabled protects them from a large class of nasty V8 vulnerabilities.

Lastly, there are workarounds for apps that really need a larger heap size. For example, it is possible to include a copy of Node.js with your app, which is built with pointer compression disabled, and move the memory-intensive work to a child process. Though somewhat complicated, it is also possible to build a custom version of Electron with pointer compression disabled, if you decide you want a different trade-off for your particular use case. And lastly, in the not-too-distant future, wasm64 will allow apps built with WebAssembly both on the Web and in Electron to use significantly more than 4GB of memory.


Perguntas Frequentes

How will I know if my app is impacted by this change?

Attempting to wrap external memory with an ArrayBuffer will crash at runtime in Electron 20+.

If you don't use any native Node modules in your app, you're safe—there's no way to trigger this crash from pure JS. This change only affects native Node modules which allocate memory outside of the V8 heap (e.g. using malloc or new) and then wrap the external memory with an ArrayBuffer. This is a fairly rare use case, but some modules do use this technique, and such modules will need to be refactored in order to be compatible with Electron 20+.

How can I measure how much V8 heap memory my app is using to know if I'm close to the 4GB limit?

In the renderer process, you can use performance.memory.usedJSHeapSize, which will return the V8 heap usage in bytes. In the main process, you can use process.memoryUsage().heapUsed, which is comparable.

What is the V8 memory cage?

Some documents refer to it as the "V8 sandbox", but that term is easily confusable with other kinds of sandboxing that happen in Chromium, so I'll stick to the term "memory cage".

There's a fairly common kind of V8 exploit that goes something like this:

  1. Find a bug in V8's JIT engine. JIT engines analyze code in order to be able to omit slow runtime type checks and produce fast machine code. Sometimes logic errors mean it gets this analysis wrong, and omits a type check that it actually needed—say, it thinks x is a string, but in fact it's an object.
  2. Abuse this confusion to overwrite some bit of memory inside the V8 heap, for instance, the pointer to the beginning of an ArrayBuffer.
  3. Now you have an ArrayBuffer that points wherever you like, so you can read and write any memory in the process, even memory that V8 normally doesn't have access to.

The V8 memory cage is a technique designed to categorically prevent this kind of attack. The way this is accomplished is by not storing any pointers in the V8 heap. Instead, all references to other memory inside the V8 heap are stored as offsets from the beginning of some reserved region. Then, even if an attacker manages to corrupt the base address of an ArrayBuffer, for instance by exploiting a type confusion error in V8, the worst they can do is read and write memory inside the cage, which they could likely already do anyway. There's a lot more available to read on how the V8 memory cage works, so I won't go into further detail here—the best place to start reading is probably the high-level design doc from the Chromium team.

I want to refactor a Node native module to support Electron 20+. How do I do that?

There are two ways to go about refactoring a native module to be compatible with the V8 memory cage. The first is to copy externally-created buffers into the V8 memory cage before passing them to JavaScript. This is generally a simple refactor, but it can be slow when the buffers are large. The other approach is to use V8's memory allocator to allocate memory which you intend to eventually pass to JavaScript. This is a bit more involved, but will allow you to avoid the copy, meaning better performance for large buffers.

To make this more concrete, here's an example N-API module that uses external array buffers:

// Create some externally-allocated buffer.
// |create_external_resource| allocates memory via malloc().
size_t length = 0;
void* data = create_external_resource(&length);
// Wrap it in a Buffer--will fail if the memory cage is enabled!
napi_value result;
napi_create_external_buffer(
env, length, data,
finalize_external_resource, NULL, &result);

This will crash when the memory cage is enabled, because data is allocated outside the cage. Refactoring to instead copy the data into the cage, we get:

size_t length = 0;
void* data = create_external_resource(&length);
// Create a new Buffer by copying the data into V8-allocated memory
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// If you need to access the new copy, |copied_data| is a pointer
// to it!

This will copy the data into a newly-allocated memory region that is inside the V8 memory cage. Optionally, N-API can also provide a pointer to the newly-copied data, in case you need to modify or reference it after the fact.

Refactoring to use V8's memory allocator is a little more complicated, because it requires modifying the create_external_resource function to use memory allocated by V8, instead of using malloc. This may be more or less feasible, depending on whether or not you control the definition of create_external_resource. The idea is to first create the buffer using V8, e.g. with napi_create_buffer, and then initialize the resource into the memory that has been allocated by V8. It is important to retain a napi_ref to the Buffer object for the lifetime of the resource, otherwise V8 may garbage-collect the Buffer and potentially result in use-after-free errors.

· Leitura de 3 minutos

Electron 19.0.0 has been released! It includes upgrades to Chromium 102, V8 10.2, and Node.js 16.14.2. Read below for more details!


The Electron team is excited to announce the release of Electron 19.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 and please share any feedback you have!

Notable Changes

Electron Release Cadence Change

The project is returning to its earlier policy of supporting the latest three major versions. See our versioning document for more detailed information about Electron versioning and support. This had temporarily been four major versions to help users adjust to the new release cadence that began in Electron 15. You can read the full details here.

Stack Changes

Breaking & API Changes

Below are breaking changes introduced in Electron 19. More information about these and future changes can be found on the Planned Breaking Changes page.

Unsupported on Linux: .skipTaskbar

The BrowserWindow constructor option skipTaskbar is no longer supported on Linux. Changed in #33226

Removed WebPreferences.preloadURL

The semi-documented preloadURL property has been removed from WebPreferences. #33228. WebPreferences.preload should be used instead.

End of Support for 15.x.y and 16.x.y

Electron 14.x.y and 15.x.y have both reached end-of-support. This returns Electron to its existing policy of supporting the latest three major versions. Developers and applications are encouraged to upgrade to a newer version of Electron.

E15 (Sep'21)E16 (Nov'21)E17 (Feb'22)E18 (Mar'22)E19 (May'22)
15.x.y16.x.y17.x.y18.x.y19.x.y
14.x.y15.x.y16.x.y17.x.y18.x.y
13.x.y14.x.y15.x.y16.x.y17.x.y
12.x.y13.x.y14.x.y15.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. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately every 2 months.

You can find Electron's public timeline here.

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

· Leitura de 2 minutos

Electron is changing its primary S3 bucket, you may need to update your build scripts


What is happening?

A significant amount of Electron's build artifacts are uploaded to an S3 bucket called gh-contractor-zcbenz. As part of ongoing infrastructure/ownership migrations that started way back in 2020, we will be changing everything that used gh-contractor-zcbenz from its old home in S3 to a new storage system hosted at https://artifacts.electronjs.org. The path prefix that most of our assets use is changing slightly as well. Examples are included below:

Before: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib
After: https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib

The important things here are the Hostname changed and the /atom-shell prefix changed. Another example, this time for debug symbols:

Before: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb
After: https://artifacts.electronjs.org/symbols/path/to/symbol.pdb

Again, the hostname changed and the /atom-shell prefix was changed.

How might this impact you?

Anyone using standard build tooling such as electron-rebuild, electron-packager or @electron/get won't have to do anything. This should be the majority of people.

For anyone directly referencing the S3 bucket, you must update your reference to point at the hostname and update the path as well.

What about existing data?

Most data that existed on the gh-contractor-zcbenz bucket has been cloned into the new storage system. This means all debug symbols and all headers have been copied. If you relied on some data in that bucket that hasn't been copied over please raise an issue in electron/electron and let us know.

The current gh-contractor-zcbenz S3 bucket will not be actively deleted. However, we can't guarantee how long that bucket will be left alive. We strongly recommend updating to target the new bucket as soon as possible.

· Leitura de 3 minutos

Electron 18.0.0 has been released! It includes upgrades to Chromium 100, V8 10.0, and Node.js 16.13.2. Read below for more details!


The Electron team is excited to announce the release of Electron 18.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 and please share any feedback you have!

Notable Changes

Electron Release Cadence Change

As of Electron 15, Electron will release a new major stable version every 8 weeks. You can read the full details here.

Additionally, Electron has changed supported versions from latest three versions to latest four versions until May 2022. See our versioning document for more detailed information about versioning in Electron. After May 2022, we will return to supporting latest three versions.

Stack Changes

Highlighted Features

  • Added ses.setCodeCachePath() API for setting code cache directory. #33286
  • Removed the old BrowserWindowProxy-based implementation of window.open. This also removes the nativeWindowOpen option from webPreferences. #29405
  • Added 'focus' and 'blur' events to WebContents. #25873
  • Added Substitutions menu roles on macOS: showSubstitutions, toggleSmartQuotes, toggleSmartDashes, toggleTextReplacement. #32024
  • Added first-instance-ack event to the app.requestSingleInstanceLock() flow, so that users can pass some data back from the second instance to the first instance. #31460
  • Added support for more color formats in setBackgroundColor. #33364

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

Breaking & API Changes

Below are breaking changes introduced in Electron 18. More information about these and future changes can be found on the Planned Breaking Changes page.

Removido: nativeWindowOpen

Prior to Electron 15, window.open was by default shimmed to use BrowserWindowProxy. This meant that window.open('about:blank') did not work to open synchronously scriptable child windows, among other incompatibilities. Since Electron 15, nativeWindowOpen has been enabled by default.

See the documentation for window.open in Electron for more details. Removed in #29405

End of Support for 14.x.y

Electron 14.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 of Electron 15, we have changed supported versions from latest three versions to latest four versions until May 2022 with Electron 19. After Electron 19, we will return to supporting the latest three versions. This version support change is part of our new cadence change. Please see our blog post for full details here.

E15 (Sep'21)E16 (Nov'21)E17 (Feb'22)E18 (Mar'22)E19 (May'22)
15.x.y16.x.y17.x.y18.x.y19.x.y
14.x.y15.x.y16.x.y17.x.y18.x.y
13.x.y14.x.y15.x.y16.x.y17.x.y
12.x.y13.x.y14.x.y15.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. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately every 2 months.

You can find Electron's public timeline here.

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

· Leitura de 2 minutos

The Electron team is excited to announce that we will be participating in Google Summer of Code for the first time this year!


What is Google Summer of Code?

Google Summer of Code (GSoC) is a yearly mentoring program connecting open source software projects with potential contributors. Previously open only to students, anyone ages 18 and up can now register for GSoC.

For more information, check out the Summer of Code homepage.

How do I sign up?

Are you interested in collaborating with Electron? If you are a new or beginner open source contributor, we welcome you to apply!

In order to be selected as an Electron contributor for Google Summer of Code, you will need to submit an application. Applications will open on April 4th, 2022 and close on April 19th, 2022. You can follow updates for Google: Summer of Code application guidelines here.

Want to apply? First, check out the five project idea drafts that we have prepared. All of the listed ideas are currently open for proposals. We are also open to accepting new ideas that are not on the proposed project list.

Your application should include:

  • Your proposal, which is a written document that describes in detail what you plan to achieve over the course of the summer.
  • Your background as a developer. If you have a resume, please include a copy, otherwise tell us about your past experience with an emphasis on relevant technical experience.

A detailed guide of what to submit as part of your Electron application is here.

You can also read through the official GSoC student/contributor guide for important tips on preparing your proposal.

If you want to discuss project proposals or have questions, come hang out in our #gsoc-general Discord channel!

Referências

· Leitura de 3 minutos

Electron 17.0.0 has been released! It includes upgrades to Chromium 98, V8 9.8, and Node.js 16.13.0. Read below for more details!


The Electron team is excited to announce the release of Electron 17.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 and please share any feedback you have!

Notable Changes

Electron Release Cadence Change

As of Electron 15, Electron will release a new major stable version every 8 weeks. You can read the full details here.

Additionally, Electron has changed supported versions from latest three versions to latest four versions until May 2022. See our versioning document for more detailed information about versioning in Electron. After May 2022, we will return to supporting latest three versions.

Stack Changes

Highlighted Features

  • Added webContents.getMediaSourceId(), can be used with getUserMedia to get a stream for a WebContents. #31204
  • Deprecates webContents.getPrinters() and introduces webContents.getPrintersAsync(). #31023
  • desktopCapturer.getSources is now only available in the main process. #30720

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

Breaking Changes

Below are breaking changes introduced in Electron 17. More information about these and future changes can be found on the Planned Breaking Changes page.

desktopCapturer.getSources in the renderer

The desktopCapturer.getSources API is now only available in the main process. This has been changed in order to improve the default security of Electron apps.

Alterações de API

There were no API changes in Electron 17.

Removed/Deprecated Changes

  • Usage of the desktopCapturer.getSources API in the renderer has been removed. See here for details on how to replace this API in your app.

End of Support for 13.x.y

Electron 13.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 of Electron 15, we have changed supported versions from latest three versions to latest four versions until May 2022 with Electron 19. After Electron 19, we will return to supporting the latest three versions. This version support change is part of our new cadence change. Please see our blog post for full details here.

E15 (Sep'21)E16 (Nov'21)E17 (Feb'22)E18 (Mar'22)E19 (May'22)
15.x.y16.x.y17.x.y18.x.y19.x.y
14.x.y15.x.y16.x.y17.x.y18.x.y
13.x.y14.x.y15.x.y16.x.y17.x.y
12.x.y13.x.y14.x.y15.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. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately every 2 months.

You can find Electron's public timeline here.

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

· Leitura de 2 minutos

Spectron will be deprecated on February 1st, 2022.


Beginning in February 2022, Spectron will be officially deprecated by the Electron team.

Why Deprecate Spectron?

While Spectron has consistently put out new releases for each new version of Electron, the project has had very little maintenance and improvements for well over a year, and currently has no full-time maintainers. With the remote module moving outside of Electron core and into an external module in Electron 14, Spectron will require a major rewrite to continue working reliably.

After reviewing several available options for Spectron's continued maintenance, the Electron team has decided to deprecate Spectron in 2022.

Deprecation Timeline

The following is our planned deprecation timeline:

  • November 2021 - January 2022: The Electron team will continue to accept pull requests from the community.
  • January 2022: A final version of announcement warning about Spectron's deprecation will be released.
  • February 1, 2022: Spectron's repo will be marked as "archived". No more pull requests will be accepted.

Following February 1st, 2022, Electron will continue to leave the Spectron repo up indefinitely, so that others are welcome to fork or use the existing code for their projects. We hope this will help provide a longer transition to any projects that may still depend on Spectron.

Alternatives to Spectron

If you're currently using Spectron in your project and would like to migrate to an alternative testing solution, you can read our guide for automated testing here.

We currently have several other recommended alternatives to Spectron, including Playwright and WebDriverIO. Official tutorials for each option can be found in our Automated Testing documentation.

What's Next

We here on the Electron team appreciate you using Spectron and Electron. We understand that many of you depend on Spectron for testing your apps, and we want to make this transition as painless for you as possible. Thank you for choosing Electron!

· Leitura de 4 minutos

Electron 16.0.0 has been released! It includes upgrades to Chromium 96, V8 9.6, and Node.js 16.9.1. Read below for more details!


The Electron team is excited to announce the release of Electron 16.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 and please share any feedback you have!

Notable Changes

Electron Release Cadence Change

As of Electron 15, Electron will release a new major stable version every 8 weeks. You can read the full details here.

Additionally, Electron has changed supported versions from latest three versions to latest four versions until May 2022. See our versioning document for more detailed information about versioning in Electron. After May 2022, we will return to supporting latest three versions.

Stack Changes

Highlighted Features

  • Now supports the WebHID API. #30213
  • Add data parameter to app.requestSingleInstanceLock to share data between instances. #30891
  • Pass securityOrigin to media permissions request handler. #31357
  • Add commandLine.removeSwitch. #30933

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

Breaking Changes

Below are breaking changes introduced in Electron 16. More information about these and future changes can be found on the Planned Breaking Changes page.

Building Native Modules

If your project uses node-gyp to build native modules, you may need to call it with --force-process-config depending on your project's setup and your Electron version. More information about this change can be found at #2497.

Behavior Changed: crashReporter implementation switched to Crashpad on Linux

The underlying implementation of the crashReporter API on Linux has changed from Breakpad to Crashpad, bringing it in line with Windows and Mac. As a result of this, child processes are now automatically monitored, and calling process.crashReporter.start in Node child processes is no longer needed (and is not advisable, as it will start a second instance of the Crashpad reporter).

There are also some subtle changes to how annotations will be reported on Linux, including that long values will no longer be split between annotations appended with __1, __2 and so on, and instead will be truncated at the (new, longer) annotation value limit.

Alterações de API

There were no API changes in Electron 16.

Removed/Deprecated Changes

  • Usage of the desktopCapturer.getSources API in the renderer has been deprecated and will be removed. This change improves the default security of Electron apps. See here for details on how to replace this API in your app.

End of Support for 12.x.y

Electron 12.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 of Electron 15, we have changed supported versions from latest three versions to latest four versions until May 2022 with Electron 19. After Electron 19, we will return to supporting the latest three versions. This version support change is part of our new cadence change. Please see our blog post for full details here.

E15 (Sep'21)E16 (Nov'21)E17 (Feb'22)E18 (Mar'22)E19 (May'22)
15.x.y16.x.y17.x.y18.x.y19.x.y
14.x.y15.x.y16.x.y17.x.y18.x.y
13.x.y14.x.y15.x.y16.x.y17.x.y
12.x.y13.x.y14.x.y15.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. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately every 2 months.

You can find Electron's public timeline here.

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