Electron22 será la última versión principal de Electron en brindar soporte para las versiones de Windows más antiguas que 10. Windows 7/8/8.1 no será soportado en Electron 23 y los próximos lanzamientos principales. Las versiones más antiguas de Electron continuarán funcionando en Windows 7, y nosotros continuaremos con el lanzamiento de parches para las series 22.x de Electron hasta el 30 de mayo de 2023, cuando Electron finalizará el soporte para 22.x (de acuerdo a nuestra línea de tiempo de soporte).
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.
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.
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.
Los lanzamientos de día cero y los lanzamientos principales relacionados con la seguridad se publicarán según sea necesario. Los incidentes de seguridad se deben reportar a través de SECURITY.md.
With the success of December Quiet Month 2021, we wanted to bring it back for 2022. December continues to be a quiet month for most companies, so we want to give our maintainers a chance to recharge. Everyone is looking forward to 2023, and we expect good things to come! Animamos a otros proyectos a considerar medidas similares.
We are excited to announce that Electron Forge v6.0.0 is now available! This release marks the first major release of Forge since 2018 and moves the project from electron-userland into the main electron organization on Github.
Keep on reading to see what's new and how your app can adopt Electron Forge!
Electron Forge is a tool for packaging and distributing Electron applications. Este unifica la construcción del ecosistema de herramientas de Electron en una única interfaz extensible para que cualquiera pueda pasar directamente a la creación de aplicaciones de Electron.
Highlight features include:
📦 Application packaging and code signing
🚚 Customizable installers on Windows, macOS, and Linux (DMG, deb, MSI, PKG, AppX, etc.)
From v1 to v5, Electron Forge was based on the now-discontinued electron-compile project. Forge 6 is a complete rewrite of the project with a new modular architecture that can be extended to meet any Electron application's needs.
In the past few years, Forge v6.0.0-beta has achieved feature parity with v5 and code churn has slowed down dramatically, making the tool ready for general adoption.
Don't install the wrong package
For versions 5 and below, Electron Forge was published to the electron-forge package on npm. Starting with the v6 rewrite, Forge is instead structured as a monorepo project with many smaller projects.
Historically, Electron maintainers have been unopinionated about build tooling, leaving the task to various community packages. However, with Electron maturing as a project, it has become harder for new Electron developers to understand which tools they need to build and distribute their apps.
To help guide Electron developers in the distribution process, we have have decided to make Forge the official batteries-included build pipeline for Electron.
Over the past year, we have been slowly integrating Forge into the official Electron documentation, and we have recently moved Forge over from its old home in electron-userland/electron-forge to the electron/forge repo. Now, we are finally ready to release Electron Forge to a general audience!
Scaffolding a new Electron Forge project can be done using the create-electron-app CLI script.
Yarn
npm
yarn create electron-app my-app --template=webpack cd my-app yarn start
npm init electron-app@latest my-app -- --template=webpack cd my-app npm start
The script will create an Electron project in the my-app folder with completely JavaScript bundling and a preconfigured build pipeline.
For more info, see the Getting Started guide in the Forge docs.
First-class webpack support
The above snippet uses Forge's Webpack Template, which we recommend as a starting point for new Electron projects. This template is built around the @electron-forge/plugin-webpack plugin, which integrates webpack with Electron Forge in a few ways, including:
enhancing local dev flow with webpack-dev-server, including support for HMR in the renderer;
handling build logic for webpack bundles before application packaging; and
adding support for Native Node modules in the webpack bundling process.
When you use the import command, Electron Forge will add a few core dependencies and create a new forge.config.js configuration. If you have any existing build tooling (e.g. Electron Packager, Electron Builder, or Forge 5), it will try to migrate as many settings as possible. Some of your existing configuration may need to be migrated manually.
If you already have tooling for packaging and publishing your Electron app, the benefits associated with adopting Electron Forge can still outweigh the initial switching cost.
We believe there are two main benefits to using Forge:
Forge receives new features for application building as soon as they are supported in Electron. In this case, you won't need to wire in new tooling support yourself, or wait for that support to be eventually implemented by other packages before upgrading. For recent examples, see macOS universal binaries and ASAR integrity checking.
Forge's multi-package architecture makes it easy to understand and extend. Since Forge is made up of many smaller packages with clear responsibilities, it is easier to follow code flow. In addition, Forge's extensible API design means that you can write your own additional build logic separate from the provided configuration options for advanced use cases. For more details on writing custom Forge plugins, makers, and publishers, see the Extending Electron Forge section of the docs.
Forge 6 has spent a long time in the beta phase, and its release cadence has gradually slowed down. However, we have accelerated development in the second half of 2022 and used the last few releases to push some final breaking changes before the v6.0.0 stable release.
If you are an Electron Forge 6 beta user, see the v6.0.0 GitHub release notes for a list of breaking changes made in recent betas (>=6.0.0-beta.65).
A complete list of changes and commits can be found in the repo's CHANGELOG.md.
Tell us what you need! The Electron Forge team is always looking to build the project to better suit its users.
You can help us improve Electron Forge by submitting feature requests, posting issues, or just letting us know your feedback! You can also join us in the official Electron Discord server, where there is a dedicated channel for Electron Forge discussion.
El mes pasado, el grupo encargado de mantener Electron se reunió en Vancouver, Canadá para discutir la dirección del proyecto para el 2023 y más adelante. Durante cuatro días, en una sala de conferencias, los encargados del mantenimiento del núcleo y los colaboradores invitados debatieron sobre las nuevas iniciativas, los problemas de mantenimiento y el estado general del proyecto. invitados debatieron nuevas iniciativas, problemas de mantenimiento y la salud general del proyecto.
En el futuro, el equipo todavía está totalmente dedicado a lanzar rápidas y normales actualizaciones de Chromium, arreglando fallos, y haciendo Electron más seguro y eficiente para todos. ¡También estamos trabajando en algunos proyectos interesantes que nos gustaría compartir con la comunidad!
Las principales propuestas de API en el proyecto Electron que requieren consenso pasan por un proceso de solicitud de comentarios (RFC), que revisan los miembros de nuestro grupo de trabajo sobre API.
Este año hemos impulsado dos importantes propuestas que tienen el potencial de desbloquear una nueva dimensión de capacidades para las aplicaciones Electron. Estas propuestas son muy experimentales, pero he aquí un de lo que puede esperar!
Esta propuesta esboza una nueva capa de APIs de Electron C que permitirá a los desarrolladores de aplicaciones escribir sus Native Node Addons que interactúen con los recursos internos de Electron, de forma similar a la propia Node-API de Node. de Node. Puede encontrar más información sobre la nueva API propuesta aquí.
Ejemplo: Supercargando aplicaciones con recursos de Chromium
Muchas aplicaciones Electron mantienen sus propias bifurcaciones para interactuar directamente con las funciones internas de Chromium que, de otro modo, serían inaccesibles con Electron vainilla (sin modificar). Al exponer estos recursos en la capa API de C este código puede vivir como un módulo nativo junto con Electron, reduciendo potencialmente la carga de mantenimiento del desarrollador de aplicaciones.
Bajo el capó, las partes no web de la interfaz de usuario (IU) de Chrome, como las barras de herramientas, las pestañas o los botones, se construyen con un marco llamado Views. La propuesta de la API Views introduce partes de este marco como clases de JavaScript en Electron, con el objetivo final de permitir a los desarrolladores crear elementos de interfaz de usuario no web para sus aplicaciones Electron. Esto evitará que las aplicaciones tengan que piratear contenidos web.
Actualmente se están sentando las bases para hacer posible este nuevo conjunto de API. Estas son algunas de las primeras cosas que puede esperar en un futuro próximo.
Ejemplo: Refactorización del modelo de ventana con WebContentsView
Nuestro primer cambio planeado es exponer WebContentsView de Chrome a la superficie API de Electron, que será la sucesora de nuestra actual API BrowserView (que, a pesar del nombre, es código específico de Electron no relacionado con Chromium Views). Con WebContentsView expuesto, tendremos un objeto View reutilizable que puede mostrar contenidos web, abriendo la puerta a convertir la clase BrowserWindow en JavaScript puro y eliminando aún más complejidad de código.
Aunque este cambio no aporta muchas funciones nuevas a los desarrolladores de aplicaciones, se trata de una gran refactorización que elimina mucho código bajo el capó, lo que simplifica las actualizaciones de Chromium y reduce el riesgo de que aparezcan nuevos errores entre versiones principales.
Si eres un desarrollador de Electron que utiliza BrowserViews en tu aplicación: no te preocupes, ¡no nos hemos olvidado de ti! Planeamos convertir la clase BrowserView existente en un shim para WebContentsView con el fin de proporcionar un amortiguador durante la transición a las nuevas API.
Ver: electron/electron#35658
Ejemplo: Contenido web desplazable con ScrollView
Nuestros amigos de Stack han estado impulsando una iniciativa para exponer el componente ScrollView de Chromium a la API de Electron. Con esta nueva API, cualquier componente View hijo puede hacerse desplazable horizontal o verticalmente.
Aunque esta nueva API cumple una única funcionalidad menor, el objetivo final del equipo es construir un conjunto de componentes de utilidad de View que puedan utilizarse como conjunto de herramientas para construir interfaces no HTML más complejas.
¿Es usted un desarrollador de aplicaciones Electron interesado en alguna de estas propuestas de API? Aunque aún no estamos preparados para recibir más RFC, manténgase atento para conocer más detalles en el futuro!
Desde la creación del framework, el ecosistema de herramientas de compilación de Electron ha sido impulsado en gran medida por la comunidad y ha consistido en muchos paquetes pequeños de un solo propósito (por ejemplo, electron-winstaller, electron-packager, electron-notarize, electron-osx-sign). Aunque estas herramientas funcionan bien, a los usuarios les resulta intimidante montar un proceso de compilación que funcione.
Para ayudar a construir una experiencia más amigable para los desarrolladores de Electron, construimos Electron Forge, una solución todo en uno que combina todas estas herramientas existentes en una sola interfaz. Aunque Forge ha estado en desarrollo desde 2017, el proyecto ha permanecido inactivo durante los últimos años. Sin embargo, dada la retroalimentación de la comunidad sobre el estado de las herramientas de construcción en Electron, hemos estado trabajando duro para lanzar la versión principal estable de próxima generación de Forge.
Electron Forge 6 incluye compatibilidad de primera clase con TypeScript y Webpack, así como una API extensible que permite a los desarrolladores crear sus propios plugins e instaladores.
Si te interesa crear un proyecto con Forge o crear plantillas o plugins con las API extensibles de terceros de Forge, estate atento a nuestro anuncio oficial sobre la versión estable de Forge v6 en algún momento de este mes!
Aparte de lo anterior, el equipo siempre está pensando en un montón de proyectos exploratorios para hacer que la experiencia Electron sea mejor para los desarrolladores de aplicaciones y los usuarios finales. Estamos experimentando con herramientas de actualización, procesos de revisión de API y documentación mejorada. Esperamos tener más noticias que compartir en un futuro próximo!
¡Electron 21.0.0 ha sido liberado! Incluye actualizaciones a Chromium 106, V8 10.6, y Node.js 16.16.0. ¡Lea a continuación para más detalles!
El equipo de Electron esta emocionado de anunciar el lanzamiento de 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.
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
Electron 18.x.y ha alcanzado el fin de soporte según la política de soporte del proyecto. Developers and applications are encouraged to upgrade to a newer version of Electron.
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.
¡Electron 20.0.0 ha sido liberado! Incluye actualizaciones a Chromium 104, V8 10.4, y Node.js 16.15.0. ¡Lea a continuación para más detalles!
El equipo de Electron esta emocionado de anunciar el lanzamiento de 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!
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. En Electron 20, este comportamiento ha cambiado. 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:
V8 headers now use c++17 by default. This flag was added to electron-rebuild.
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.
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.
Electron 17.x.y ha alcanzado el fin de soporte según la política de soporte del proyecto. Developers and applications are encouraged to upgrade to a newer version of Electron.
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.
Electron 21 and later will have the V8 Memory Cage enabled, with implications for some native modules.
Update (2022/11/01)
To track ongoing discussion about native module usage in Electron 21+, see electron/electron#35801.
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:
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.
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.
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?
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:
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.
Abuse this confusion to overwrite some bit of memory inside the V8 heap, for instance, the pointer to the beginning of an ArrayBuffer.
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 21+. 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.
¡Electron 19.0.0 ha sido liberado! Incluye actualizaciones a Chromium 102, V8 10.2y Node.js 16.14.2. ¡Lea a continuación para más detalles!
El equipo de Electron esta emocionado de anunciar el lanzamiento de 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!
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.
Below are breaking changes introduced in Electron 19. More information about these and future changes can be found on the Planned Breaking Changes page.
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.
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.
Electron está cambiando su S3 bucket principal, es posible que debas actualizar tus scripts de construcción
¿Qué está pasando?
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. Los ejemplos se incluyen a continuación:
Again, the hostname changed and the /atom-shell prefix was changed.
¿Cómo puede influir en ti?
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.
¿Qué pasa con los datos existentes?
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.
¡Electron 18.0.0 ha sido liberado! Incluye actualizaciones a Chromium 100, V8 10.0y Node.js 16.13.2. ¡Lea a continuación para más detalles!
El equipo de Electron esta emocionado de anunciar el lanzamiento de 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!
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.
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 a first-instance-ack event to the app.requestSingleInstanceLock() flow, allowing users to seamlessly transmit data from the first instance to the second instance. #31460
Added support for more color formats in setBackgroundColor. #33364
Below are breaking changes introduced in Electron 18. More information about these and future changes can be found on the Planned Breaking Changes page.
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.
Electron 14.x.y ha alcanzado el fin de soporte según la política de soporte del proyecto. 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.
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.
