When Electron switched to Wayland on Linux last fall, most people didn't notice.

Major Linux distributions adopted the modern display protocol years ago, and both the KDE Plasma and GNOME desktop environments are in the process of dropping X11 support completely.

But a platform migration isn't complete without apps, and a large part of the Linux app ecosystem went through a second Wayland transition last August — well after most distros had changed their defaults. That's when Chromium turned on Wayland by default, bringing Electron and dozens of Linux desktop apps along with it.

The third impact: Electron goes Wayland-native​

Wayland is supported out of the box in Electron 38.2 and newer. As long as your apps are up-to-date, it just works. (If you were previously launching your Electron apps with very long commands like CONFUSING_OZONE_VARIABLE --ozone-platform=wayland, you no longer need to do that.)

This change was possible because the Chromium and Electron projects have been working on Wayland support for more than half a decade. But until recently, Chrome and Electron apps continued to use X11 by default, even when launched in a Wayland session. This wasn’t a big issue, since X11 apps still work fairly well on Wayland by running inside an invisible X server called Xwayland.

Running apps through a compatibility layer is not the same as running them directly on Wayland. On Wayland, there’s less sitting between your app and the compositor, so there's lower overhead and much stronger isolation between applications. Modern Wayland compositors also let apps take advantage of newer platform and display features like variable refresh rates, HiDPI and fractional scaling, and HDR.

These are all good reasons for Electron to make the switch. In late September, Electron followed Chromium’s lead and began defaulting to Wayland. And as apps began to update, people who had been “using Wayland” without issues for months or years started to find out what it was really like to experience their apps on Wayland for the first time.

Wayland’s house, Wayland’s rules​

Supporting Wayland required dozens of changes throughout Chromium and Electron, from internals to developer-facing APIs. It also required a different way of thinking about what desktop apps should be able to do.

Wayland reconsiders assumptions made by older systems and asks whether apps should be able to:

• Take focus away from other apps
• View and interact with windows from other apps
• Respond to mouse and keyboard input when not focused
• Choose where to position their own windows on the screen (and which physical monitor to appear on)
• Resize their windows at any time

Wayland's answer to these questions is essentially “no.” When you open a window, the compositor — not the app developer — decides where it goes. Apps cannot unilaterally move, resize, or focus their windows without user input, and they can only interact with the rest of the desktop through optional protocol extensions and XDG portals.

These kinds of rules are understandable; no one likes it when a misbehaving app steals focus or loads halfway off the screen. But it can still surprise people when their apps suddenly lose access to familiar affordances on Wayland. This is especially the case for a cross-platform framework like Electron, which exists to help developers achieve consistent results everywhere.

Some widely used Electron APIs that work on X11, macOS, and Windows are not available on Wayland. For example, win.setPosition(x, y) and screen.getCursorScreenPoint() aren't supported, as Wayland deliberately forbids apps from accessing global screen coordinates.

Other features work differently: recording the screen with desktopCapturer and setting keyboard shortcuts with globalShortcut are more restricted, and both heavily depend on the desktop environment and portal versions. Here's what it looks like when screen sharing in Signal Desktop on GNOME 48.

Making this more complicated for developers is the fact that Wayland isn't a single piece of software, but a protocol. Every compositor implements it a little differently, almost like browser engines. (There are even protocol support trackers that look like they came from MDN or CanIUse.)

So when Slack tries to focus its main window with win.focus(), GNOME's compositor (Mutter) shows a notification. On KDE Plasma (KWin), the app icon flashes in the panel instead. Neither outcome is what the app's developers had in mind, but both are valid interpretations of the activation spec.

Some capabilities simply work better on Wayland than on X11, including anything to do with colors, transparency, and hardware-accelerated rendering. win.setOpacity(n) is an example of an Electron API which hasn't been available on Linux in the past, but which will now be feasible to support.

Even the stricter restrictions can benefit apps. When 1Password runs on Wayland, its SSH agent lets users confirm requests with a single click instead of asking them to enter their passwords. This is safe because Wayland's input isolation is strong enough to prevent the prompt from being skipped with clickjacking — only a real human being can click the button.

The basic tradeoff is that Wayland restricts some of what apps can do but also enables them to be more capable and secure. And in one area, Wayland gives developers more flexibility and more responsibility than before: client-side decorations (CSD).

Understanding CSD, or when a window isn’t a window​

The Wayland protocol is very lightweight, and its simplicity extends to the way it draws window frames. On X11, the window manager typically supplies a window’s title bar and frame decorations. But when you create a window (xdg_toplevel) on Wayland, all you get back from the compositor is a plain rectangle.

That rectangle is a powerful canvas. On a modern compositor like GNOME’s Mutter, it’s triple-buffered and GPU-accelerated. But if you want any of the trimmings users might expect — title bar buttons, drop shadows, even resize handles — you have to add them yourself. This requirement is called client-side decorations (CSD), and it’s one of the major differences between X11 and Wayland.

Electron already had some support for client-side decorations, provided by a class called ClientFrameViewLinux which uses GTK to paint convincing native window frames. These look very similar to the ones GNOME used to supply on X11, but they are produced entirely in-framework.

But client-side window frames are not an exact match for server-side decorations (SSD) from X11 window managers. They need to be implemented by each app or framework, so the details can look noticeably different when you put apps side by side, from their title bar areas right down to their drop shadows and corner shapes.

The differences are usually minor, but when CSD is completely absent from a window, the result can be visually jarring.

Many popular apps, including Visual Studio Code, Obsidian, and Discord, use frameless windows with custom title bars. Prior to Electron 41, frameless windows did not support CSD at all, so they looked like featureless rectangles on Wayland.

Improving coverage for CSD was a task with framework-wide consequences. The biggest obstacle involved window sizes and how to measure and set them accurately. Electron already manages two different kinds of window boundaries:

• “window bounds”, the size of the window, including its titlebar, menubar, and frame.
• “content bounds”, the size of the internal web view which hosts the app’s web content.

Both values can be controlled independently. If a developer calls for an 800x600 window, Electron calculates the height of the title bar and shrinks the web app to something like 800x540. (It also works the other way around for content-sized windows.)

To support CSD, Electron also needed to keep track of a new kind of boundary:

• “widget bounds”, the size of the transparent widget which draws everything inside of it, including the window frame and its external decorations.

When CSD is required, Electron first takes the window's underlying surface (accessed internally via a Chromium accelerated widget) and inflates it so it's large enough to fit all the decorations.

The framework then paints the opaque bits of the window (title bar, frame, and web content) at their appropriate sizes and positions inside the transparent widget. The outermost areas are filled in with drop shadows and resize hit targets, creating the look and feel of a native, three-dimensional window without relying on server-side decorations.

With CSD, a "logical" window at 800x600 might be inset into a 840x640 widget. The exact geometries depend on the user's theme and the window's state: whether it is currently active, maximized, tiled, or fullscreen can affect the size and presence of decorations.

Of course, widget bounds should never leak into the public API. The framework needs to abstract this complexity away from app developers, who are generally not thinking about the extents of resize targets or shadow insets changing underneath them.

The good news is that much of this was sorted out between last September and March, and as a result, Electron 41 supports CSD on Wayland in all window configurations, including frameless windows with Window Controls Overlay.

What’s next — and how you can help​

Wayland is an everyday reality for Linux users in 2026, so a great Wayland experience is now just what it means to support Linux.

Electron reached an important milestone last month with the creation of a Wayland test job in CI. More tests still need to be ported over, but it’s now much easier to catch regressions.

Now that the basic support is in place, Wayland opens up new possibilities for Electron apps. CSD in particular offers developers more ways to customize window frames and integrate them with both their web content and the platform. Let us know what you'd like to see; one feature that's high on my own shortlist is rounded corners.

The framework is only part of the story. If you develop an Electron app and you haven’t thoroughly tested it on Linux in a while (even as recently as last fall), give it a spin with Electron 41+ on a modern distribution like Ubuntu 25.10 or Fedora 43. Try your app on both KDE Plasma and GNOME, and maybe something more exotic like Niri.

You may discover changes you could make to accommodate Wayland's unique constraints. Some differences are covered in the Electron documentation, but the best way to understand the new environment is to use it.

And if you’d like to see faster progress and support for more platform features, consider becoming a contributor. Like Linux itself, Electron is a community-run free software project that’s open to everyone, and we're actively looking for Linux contributors and maintainers.

Electron powers many of the most popular desktop apps across platforms, so getting involved is an effective way to help make desktop Linux more viable for millions of people.

The Electron team is excited to announce the release of Electron 41! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables​

ASAR Integrity digest for improved security​

As of Electron 41, macOS Electron apps can now embed a digest of their ASAR Integrity information. This adds an additional layer of tamper detection for apps that use ASAR Integrity by validating the integrity information itself at app launch.

To enable the feature for your app, you can run the following command with @electron/asar v4.1.0 and above:

asar integrity-digest on /path/to/YourApp.app

You must re-sign your app afterwards. For more information, see the @electron/asar CLI documentation.

Support for this feature in Electron Forge is planned for the near future (electron/forge#4159).

Improved Wayland support​

On Wayland (Linux), frameless windows now have drop shadows and extended resize boundaries. To create fully frameless windows with no decorations, set hasShadow: false in the window constructor. #49885

Mitchell Cohen is writing a blog article about recent work to improve Electron's support of Wayland and client-side decorations on Linux. Watch this space!

Added support for MSIX auto-updating​

The Electron team recently added MSIX auto-updater support according to RFC #21. You can now ship both MSIX and Squirrel.Mac in your update server essentially with the same JSON response format. See the autoUpdater documentation for more information.

This was added in Electron 41 by #49586 and has also been backported to Electron 39.5.0 (#49585) and 40.2.0 (#49587).

Changements de la Stack​

• Chromium 146.0.7680.65

  • Nouveau en 146
  • Nouveau en 145

• Node v24.14.0

  • Blog de publication de Node 24.14.0
  • Blog de publication de Node 24.13.1
  • Blog de publication de Node 24.13.0
  • Blog de publication de Node 24.12.0

• V8 14.4

  • V8 roll increment

Electron 41 upgrades Chromium from 144.0.7559.60 to 146.0.7680.65, Node.js from v24.11.1 to v24.14.0, and V8 from 14.4 to 14.6.

Nouvelles fonctionnalités et améliorations​

• Added --disable-geolocation command-line flag for macOS apps to disable location services. #45934
• Added NV12 support for import shared texture. #48922 ^{(Also in 40)}
• Added a disclaim option to the utilityProcess API to allow for TCC disclaiming on macOS. #49693 ^{(Also in 39, 40)}
• Added a reason property to the Notification 'closed' event on Windows to allow developers to know the reason the notification was dismissed. #50029 ^{(Also in 40)}
• Added an usePrinterDefaultPageSize option to webContents.print() to allow using the printer's default page size. #49812
• Added support for WebSocket authentication through the login event on webContents. #48512 ^{(Also in 39, 40)}
• Added support for the Node.js --experimental-transform-types flag. #49882 ^{(Also in 39, 40)}
• Added support for long-animation-frame script attribution (via --enable-features=AlwaysLogLOAFURL). #49773 ^{(Also in 39, 40)}
• Added the ability to disable auto-focusing of WebContents on navigation using webPreferences.focusOnNavigation. #49511 ^{(Also in 40)}
• Irrelevant errors from the Chromium DevTools frontend are now silenced in the main process. #49292 ^{(Also in 40)}
• Enable V8 trap handlers for WASM behind WasmTrapHandlers fuse. #49839
• Extended actions support for Windows notifications to include buttons, select dropdowns, and replies. #49787 ^{(Also in 40)}

Changements majeurs avec rupture de compatibilité​

Behavior Changed: PDFs no longer create a separate WebContents​

Previously, PDF resources created a separate guest WebContents for rendering. Now, PDFs are rendered within the same WebContents instead. If you have code to detect PDF resources, use the frame tree instead of WebContents.

Under the hood, Chromium enabled a feature that changes PDFs to use out-of-process iframes (OOPIFs) instead of the MimeHandlerViewGuest extension.

Behavior Changed: Updated Cookie Change Cause in the Cookie 'changed' Event​

We have updated the cookie change cause in the cookie 'changed' event. When a new cookie is set, the change cause is inserted. When a cookie is deleted, the change cause remains explicit. When the cookie being set is identical to an existing one (same name, domain, path, and value, with no actual changes), the change cause is inserted-no-change-overwrite. When the value of the cookie being set remains unchanged but some of its attributes are updated, such as the expiration attribute, the change cause will be inserted-no-value-change-overwrite.

Fin du support pour 38.x.y​

Electron 38.x.y a atteint sa fin de support conformément à la politique de support du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications. See https://releases.electronjs.org/schedule to see the timeline for supported versions of Electron.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

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

L’équipe d'Electron est heureuse d’annoncer la sortie d’Electron 40.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements de la Stack​

• Chromium 144.0.7559.60

  • Nouveau en 144
  • Nouveau en 143

• Node v24.11.1

  • Blog de publication de Node 24.11.1

• V8 14.4

  • V8 roll increment

Electron 411.1 met à jour Chromium de 1414.4.0.7444.52 à 144.0.7559.60, Node de 20.0.0 à 14.2.0 et V8 de à.

Nouvelles fonctionnalités et améliorations​

• Ajout de "memory-eviction" comme raison possible pour un processus fils de se terminer. #48362
• Ajout de l'option bypassCustomProtocolHandlers à net.request. #48883 ^{(Also in 38, 39)}
• Ajout du support pour importer des textures partagées externes en tant que VideoFrame. #48831
• Donne automatiquement le focus aux DevTools lorsqu'un élément est inspecté ou qu'un point d'arrêt est déclenché. #46386 ^{(Also in 37, 38, 39)}
• Activé la réinitialisation de la couleur d'accentuation pour suivre les paramètres d'accentuation du système si une couleur précédente a été définie via window.setAccentColor(null). #48274 ^{(Also in 38, 39)}
• Mise à jour de nativeImage.createFromNamedImage pour prendre en charge les noms de symboles SF. #48772 ^{(Also in 39)}

Changements majeurs avec rupture de compatibilité​

Obsolète : accès à l'API du presse-papiers depuis les processus de rendu​

L'utilisation de l'API de presse-papiers directement dans le processus de rendu est dépréciée. Si vous voulez appeler cette API à partir d'un processus de rendu, placez l'appel API dans votre script de préchargement et exposez-le en utilisant l'API contextBridge.

Comportement modifié : les fichiers dSYM macOS sont maintenant compressés avec tar.xz​

Les symboles de débogage pour macOS (dSYM) utilisent maintenant la compression xz afin de gérer les plus grandes tailles de fichiers. Les fichiers dsym.zip sont maintenant des fichiers dsym.tar.xz. Les utilisateurs finaux utilisant des symboles de débogage peuvent avoir besoin de mettre à jour leurs utilitaires zip.

Fin du support pour 37.x.y​

Electron 37.x.y a atteint sa fin de support conformément à la politique de support du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

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

Recently, I worked on improving Electron and Chromium's window resize behavior.

Le bug​

Nous avons observé un problème sous Windows où des anciennes frames deviennent visibles en redimensionnant une fenêtre:

What made this bug particularly interesting?​

1. It was challenging.
2. It was deep in a large codebase.
3. As you'll see later, there were two different bugs under the hood.

Fixing the bug​

With a bug like this, the first challenge is figuring out where to start looking.

Electron builds upon Chromium, the open source version of Google Chrome. When compiling Electron, Electron's source code is added into the Chromium source tree as a subdirectory. Electron then relies on Chromium's code to provide most of the functionality of a modern browser.

Chromium a environ 36 millions de lignes de code. Electron est également un grand projet. Cela fait beaucoup de code qui pourrait causer ce problème.

Narrowing down the root cause​

I did a lot of experimentation.

First, I noticed that the issue occurred in Google Chrome, too:

This suggested that the issue was likely in Chromium, not in Electron.

Additionally, the issue was not visible on macOS. That suggested that it was in Windows-specific source code.

The crucial lead​

I tried a lot of different command line flags and configuration options.

I noticed that app.disableHardwareAcceleration() fixed the issue. Without hardware acceleration, the issue was gone.

Here is some context: Chromium supports various different graphics APIs for showing pixels on screen (OpenGL, Vulkan, Metal, and more). On Windows, it uses different graphics APIs than on macOS or Linux. Even on Windows, Chromium can work with multiple different graphics backends.

Which graphics backend Chromium uses depends on the user's hardware. For example, some graphics backends require the computer to have a GPU.

I tried various graphics backends and noticed that the following flags fixed the issue:

• --use-angle=warp
• --use-angle=vulkan
• --use-gl=desktop
• --use-gl=egl
• --use-gl=osmesa
• --use-gl=swiftshader

The following flags reproduced the issue:

• --use-angle=d3d11 (this is currently the default on Windows)
• --use-angle=gl (falls back to Direct3D 11 on Windows, see chrome://gpu/)

None of the working flags were good enough to be used as the default in Electron apps on Windows. They were either too slow or lacked broad driver support.

However, these workarounds pointed me into the right direction. They showed that the issue was in a code path that was only used with the ANGLE Direct3D 11 backend.

Direct3D is a Windows API for hardware-accelerated graphics.

ANGLE is a library that translates OpenGL calls into calls to the native graphics API of the given operating system, here Direct3D. ANGLE allows Chromium developers to write OpenGL calls on all platforms. ANGLE then translates them into Direct3D, Vulkan, or Metal API calls, depending on which graphics API is used.

Localisation du composant Chromium concerné​

Chromium references Direct3D in tens of thousands of places. It wasn't realistic to go through all of them.

By chance, I stumbled across a few helpful debugging flags in the Chromium source code:

• --ui-show-paint-rects
• --ui-show-property-changed-rects
• --ui-show-surface-damage-rects
• --ui-show-composited-layer-borders
• --tint-composited-content
• --tint-composited-content-modulate
• (Et bien plus)

They highlight areas of the browser window that were redrawn or updated by different parts of the Chromium graphics stack.

That allowed me to see which part of the graphics stack was producing which output.

In particular, the combination of --tint-composited-content and --tint-composited-content-modulate was really helpful. The former adds a tint to the output of the compositor. The latter changes the tint color on every frame.

In the screenshot, the cyan-tinted frame was the last frame that was being drawn.

The jank to the right of that frame was not tinted cyan. It was tinted in different colors that were still there from previous frames. This indicated that the jank was not coming from the compositor. The compositor was sending the right output.

The compositor is part of Chromium's graphics stack. The following is very simplified, but for the purpose of this blog post you can imagine it like this:

1. The compositor cc produces a CompositorFrame, which contains draw instructions.
2. cc sends that CompositorFrame to the display compositor viz.
3. viz then draws the frame and shows it on screen.

Tinting each CompositorFrame showed that the compositor produced the right output. So the issue had to be in the display compositor viz.

Localisation du code viz pertinent​

From there, I started searching for mentions of Direct3D in the viz source code.

Note: From here on, the post will get a bit more technical and reference source code symbols.

I found that on the ANGLE Direct3D 11 backend, Chromium uses the Windows DirectComposition API for drawing the window contents.

Chromium's DirectComposition OutputSurface differs from most other output surfaces in Chromium. It has the capability supports_viewporter (source link 1, source link 2).

An output surface is a bitmap that can be drawn to, often backed by a GPU texture.

Without supports_viewporter, whenever the window size changes, Chromium will create a new output surface matching the new window size. Then it will draw on that surface and show it.

supports_viewporter tries to reduce these costly surface allocations. With supports_viewporter, Chromium will not allocate a new surface on every resize. Instead, it will allocate a surface that is too large for what we need to draw. Then it will only paint to and show a certain sub-rectangle (the "viewport") of that surface on screen. The other parts of the surface are not supposed to be shown on screen.

This is supposed to make resizing more efficient because all Chromium needs to do is pad the surface to the proper width and height instead of allocating a new surface on every resize. This surface resize logic lives in direct_renderer.cc.

Here's what that looks like:

Let me explain:

• The blue rectangle is our surface.
• The green area is our viewport, i.e., the area of the surface that is supposed to be visible and that we actively draw to.
• The red rectangle is our clip rect(angle), i.e., the part of the surface that is actually being shown on screen.

As a performance optimization, only the viewport (the green area) is repainted when we get a new frame. The rest is left unchanged. This is important. We only ever repaint the green viewport. We don't update the areas outside of the viewport.

When we resize the window, what's supposed to happen is that in an atomic transaction (= at the exact same time) we repaint the viewport (= the area that's supposed to be visible on screen) and then update the clip rect to clip the surface to the new viewport size.

After the resize, it should look like this:

And that's where we get to the first of our two bugs.

Premier bug​

Sometimes these operations can get out of sync. For example, the clip rect might get updated before the viewport is repainted. Then we get a result like this:

We still show the old frame in the green viewport. But the clip rect has become larger and we show areas of the surface that we haven't repainted yet.

On the first resize of a window, these areas would be black. On the second resize, those areas would be filled with old pixel values. They would show whatever we had previously painted in those areas.

Similarly, in a certain edge case while making the window smaller, we would sometimes repaint the viewport before we would update the clip rect.

Then parts of the clip rect would still show the previous frame because the new frame was smaller and we did not repaint any areas beyond the new viewport.

Now why do these operations not happen in sync?

We use two different Windows APIs here:

• IDXGISwapChain1::Present1 — This shows the new pixels on screen / updates the new viewport.
• IDCompositionDevice::Commit — This updates the clip rect.

Here's what's important to understand: both functions return synchronously on the CPU. However, they schedule tasks that run asynchronously on the GPU at a later time. Windows and its services (such as DWM) decide when these tasks will run and in which order. So they take effect asynchronously, and not always within the same frame.

Unfortunately, Windows provides no way for us to synchronize those operations. So I had to find other approaches to fix this.

There were two options that I evaluated with the Chromium maintainers:

1. While resizing, paint all previously drawn areas outside of the viewport transparent. This makes those areas invisible. It fixes the artifacts.
2. While resizing, switch from an IDXGISwapChain1 to a DirectComposition surface which synchronizes updates with IDCompositionDevice::Commit. This also fixes the artifacts.

We went with the first option because it leads to faster resizes than the second option.

I landed a patch in Chromium that implemented that first solution.

I also submitted two other patches in preparation for the main patch:

1. The first one fixed a bug in existing code that would make CI fail in combination with the main patch. It also made launching Electron apps and Chrome a tiny bit faster.
2. The second one was split off to make code review easier on the main patch.

Deuxième bug​

In addition to this first bug, there was a second bug which also led to stale pixels.

Here's what was going on there:

When the user resizes the window, Chromium needs to redraw the contents of the window for the new window size. This takes some time. The new frame isn't ready immediately.

Here's a sequence of frames that demonstrates this:

At a certain time during the resize, Windows tells us: "The window is 1,000 pixels wide." But the frames that the browser compositor produces are lagging behind. The last frame that we have painted might be 600 pixels wide.

Historically, Chromium used to skip frames where the width of the window did not match the width of the frame that it last painted. It would decide to just not update the window.

However, that would often lead to the window contents not being updated at all until the resize operation was finished.

So in 2015 someone decided: "Why not show these frames? They might not match the window size perfectly, but at least we can show something."

It would lead to gutter, but at that time the gutter was black. So that was better than the previous implementation.

Now, 10 years later with DirectComposition, that gutter was often filled with stale pixels.

Let's look at what was happening there:

Every frame consists of multiple render passes. These render passes represent the various things that should be drawn on screen. From complicated bitmaps to rectangles filled with solid colors.

Every frame has a root render pass, which contains all other render passes and glues them together. (Render passes are arranged in a tree structure and the root render pass is the root of that tree.)

So now during a resize, we'd get to a point where we know the window is 1,000 pixels wide. Accordingly, we'd adjust the viewport of our output surface to also be 1,000 pixels wide. But the frame that we just received is only 600 pixels wide.

The optimization from 2015 would then go and change the width of the root render pass to also be 1,000 pixels. But it wouldn't change what the render passes would actually draw on screen. They'd still only contain instructions to draw a picture that is 600 pixels wide.

Here's what that would look like:

The yellow area is the area in which the render passes of the frame actually drew something. It's 600 pixels wide.

However, our green viewport and our red clip rect are 1,000 pixels wide. That's the area that we show on screen. (After all, the width attribute of the root render pass claimed that it would redraw the full area of 1,000 pixels.)

But because we had no draw instructions for the 400 pixels on the right, those areas didn't get updated.

On the first resize, we'd show black pixels there. (That's the color that we initialize the surface with.)

On subsequent resizes, those areas would show whatever was drawn to them before. We'd see stale pixels.

I landed a fix for this issue in crrev.com/c/7156576.

The fix changes what we do when we receive a frame with a different size than our window. Instead of resizing the frame and adding gutter that contains stale pixels, we resize our viewport and our clip rect.

We clip our surface to the size of the frame that we received. We don't show anything beyond the 600 pixels that we have draw instructions for.

Voilà, no more gutter, no more stale pixels!

Report des correctifs dans Electron​

Once the fixes made it into Chromium, we had to pull them into Electron, too.

On the main branch, Electron updates its Chromium version constantly. As a result, the patches were merged into main in a Chromium roll PR.

However, commits that make it into main right now will only be included in an Electron release in about three months. Our existing release and pre-release branches run on older Chromium versions.

Thus, the next step was to backport the patches to Electron 39 and Electron 40.

Electron keeps a list of Chromium patches in the patches/chromium directory. When we backport a Chromium patch, we add it there. When building Electron, these patches are applied to the Chromium source code.

(In general, we try to keep the number of Chromium patches low. Every patch can lead to merge conflicts during Chromium updates. The maintenance burden from patches is real.)

The Electron 39 backport PR was merged pretty quickly. The fix became part of Electron 39.2.6. 🎉

If you resize a window on Electron 39.2.6 or later, you'll see no more stale pixels.

(The patches are also part of Google Chrome Canary. They should be part of a stable Google Chrome release in February 2026.)

Merci​

Un grand merci à Plasticity pour avoir financé ce travail !

Thanks to Michael Tang and Vasiliy Telezhnikov from the Chromium team for their help.

Réflexions finales​

Ce fut le bug le plus compliqué sur lequel j'ai travaillé (et j'ai travaillé sur de nombreux bug en 18 ans d'écriture de logiciels).

Mais c'était aussi l'un des projets les plus amusants sur lesquels j'ai travaillé.

Si vous avez trouvé cela intéressant, pensez à contribuer à Electron ! Nous apprécions voir de nouveaux visages.

Depuis 2020, Décembre a été le moment pour les responsables du projet de prendre une pause ou de se concentrer sur les tâches de maintenance régulières. Cette pause nous aide à nous reposer et à revenir dynamisé pour l'année à venir.

Cela dit, une pause d'un mois comme celui-ci n'est réalisable que lorsqu'un projet open-source est dans un état sain — nous aimerions remercier tous les responsables et contributeurs externes pour tous leurs efforts continus pour maintenir le projet en mouvement. ❤️

Revue de 2025​

À mesure que nous clôturerons l’année, nous aimerions mettre en lumière certains des projets que nous avons réalisés. Voici quelques choses dont nous pouvons être fiers en 2025:

• ⚛️ Livraison de 6 nouvelles versions majeures d'Electron en tandem avec toutes les autres versions majeures de Chromium.
• 🌿 Migration des outils de compilation d'Electron depuis Ninja vers Siso, le nouveau système de compilation de Chromium, qui ajoute la prise en charge native de l'exécution à distance.
• ✨ Remaniement de la page releases.electronjs.org avec un tout nouveau design.
• ✅ Quatre nouveaux RFCs ont étét acceptés et deux autres implémentés dans electron/electron.
• ☀️ Complétion de deux nouveaux projets Google Summer of Code :
  • L'extension DevTools IPC tracker de Devtron est maintenant disponible via npm install --save-dev @electron/devtron.
  • L'[API Save/Restore Window State] (https://github.com/electron/rfcs/blob/main/text/0016-save-restore-window-state.md) pour le module BaseWindow d'Electron a été accepté en tant que RFC et attend sa fusion finale dans le cœur d'Electron.
• 📦 Publication de versions majeures modernisées pour tous les packages npm @electron/ en tant de modules ECMAScript nécessitant au moins Node 22.
• 🔒 Déplacement de la publication des packages depuis Continuous Auth vers le nouveau système de publication fiable basé sur OIDC et sans jeton à la lumière des incidents de sécurité dans l'écosystème npm.
• 🧑‍💻 Embarquement de cinq nouveau mainteneurs qui nous aident à expédier des logiciels géniaux tous les jours et à maintenir le projet à long terme.

Merci pour une excellente année, et rendez-vous en 2026!

Politiques de période calme​

Peu a changé par rapport aux années précédentes, mais nous avons modifié une partie des libellés autour des problèmes et des demandes d'ajout pour tempérer les attentes, mais permettre aux mainteneurs de continuer à s'engager dans le projet autant qu'ils le souhaitent.

Ce qui ne changera pas en Décembre​

1. Les versions zero-day et autres versions majeures liées à la sécurité seront publiées si nécessaire. Les incidents de sécurité doivent être signalés via la politique d'escalade décrite dans le document SECURITY.md.
2. Les signalements du Code de conduite et la modération se poursuivront normalement.

Ce qui sera différent en Décembre​

1. La publication des dernières versions stable de la branche de l'année pour Electron 37, 38 et 39 auront lieu la semaine du 1er décembre. Il n'y aura pas de nouvelles sorties prévues en décembre.
2. Il n'y aura pas de publication des versions nightly, alpha et beta pour les deux dernières semaines de Décembre.
3. Les réunions régulières du Groupe de Travail seront suspendues.
4. Le tri des problèmes pourra être retardé.
5. Les demandes d'ajout et fusions pourront être retardées.

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 39.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables​

ASAR Integrity graduates to stable​

A long-standing "experimental" feature -- ASAR integrity -- is now stable in Electron 39. When you enable this feature, it validates your packaged app.asar at runtime against a build-time hash to detect any tampering. If no hash is present or if there is a mismatch in the hashes, the app will forcefully terminate.

See the ASAR integrity documentation for full information on how on the feature works, on how to use it in your application, and how to use it in Electron Forge and Electron Packager.

Pour les nouvelles connexes, Electron Packager v19 active maintenant ASAR par défaut. #1841

Changements de la Stack​

• Chromium 142.0.7444.52
  • Nouveau en 142
  • Nouveau en 141
• Node 22.20.0
  • v22.20.0 Announcement
  • v22.19.0 Announcement
• V8 14.2
  • V8 roll increment

Electron 39 met à jour Chromium de 1414.0.0.7339.41 à 142.0.7444.52, Node de 22.18.0 à 20.0.0 et V8 de 14.2 à ``.

Nouvelles fonctionnalités et améliorations​

• Added app.isHardwareAccelerationEnabled(). #48680
• Added RGBAF16 output format with scRGB HDR color space support to Offscreen Rendering. #48504
• Added methods to enable more granular accessibility support management. #48625
• Added support for USBDevice.configurations. #47459
• Added the ability to retrieve the system accent color on Linux using systemPreferences.getAccentColor. #48628
• Allowed for persisting File System API grant status within a given session. #48326 ^{(Also in 37, 38)}
• Support dynamic ESM imports in non-context isolated preloads. #48488 ^{(Also in 37, 38)}
• Marked the ASAR integrity feature as stable. It had previously been experimental. #48434

Changements majeurs avec rupture de compatibilité​

Deprecated: --host-rules command line switch​

Chromium is deprecating the --host-rules switch.

You should use --host-resolver-rules instead.

Behavior Changed: window.open popups are always resizable​

Per current WHATWG spec, the window.open API will now always create a resizable popup window.

To restore previous behavior:

webContents.setWindowOpenHandler((details) => {
  return {
    action: 'allow',
    overrideBrowserWindowOptions: {
      resizable: details.features.includes('resizable=yes'),
    },
  };
});

Behavior Changed: NSAudioCaptureUsageDescription should be included in your app's Info.plist file to use desktopCapturer (🍏 macOS ≥14.2)​

Due to a Chromium update which enables Apple's newer CoreAudio Tap API by default, you now must have NSAudioCaptureUsageDescription defined in your Info.plist to use desktopCapturer.

Electron's desktopCapturer will create a dead audio stream if the new permission is absent. However, no errors or warnings will occur. This is partially a side-effect of Chromium not falling back to the older Screen & System Audio Recording permissions system if the new system fails.

To restore previous behavior:

//main.js (right beneath your require/import statments)
app.commandLine.appendSwitch(
  'disable-features',
  'MacCatapLoopbackAudioForScreenShare',
);

Behavior Changed: shared texture OSR paint event data structure​

When using the shared texture offscreen rendering feature, the paint event now emits a more structured object. It moves the sharedTextureHandle, planes, modifier into a unified handle property. See the OffscreenSharedTexture documentation for more details.

Fin du support pour 36.x.y​

Electron 36.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

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

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 38.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements de la Stack​

• Chromium 140.0.7339.41
  • Nouveau en 140
  • Nouveau en 139
• Node 22.18.0
  • Notes Node 22.18.0
• V8 14.0
  • V8 roll increment

Electron 38 met à jour Chromium de 138.0.7204.35 à 140.0.7339.41, Node de 22.16.0 à 22.18.0, et V8 de 13.8 à 14.0.

Nouvelles fonctionnalités et améliorations​

• Added support for customizing system accent color and highlighting of active window border. #47285 (Également en 37)
• Added fileBacked and purgeable fields to process.getSystemMemoryInfo() for macOS. #48146 (Également en 37)
• Ajout du support de l'option constructeur guid du Tray` sur macOS pour permettre aux icônes de la zone de notification de maintenir leur position aux travers des lancements. #48077 (Également en 37)
• Added webFrameMain.fromFrameToken(processId, frameToken) to get a WebFrameMain instance from its frame token. #47942
• Added support for app.getRecentDocuments() on Windows and macOS. #47924 (Également en 37)
• Internally switched to using DIR_ASSETS instead of DIR_MODULE/DIR_EXE to locate assets and resources, and added "assets" as a key that can be queried via app.getPath. #47950 (Également en 37)
• Fixed an issue where dialog.showMessageDialog showed a window incorrectly centered to monitor instead of parent window when passed. #48215
• Correction d'un problème qui empêchait les utilisateurs sur macOS d'interagir avec une page Web chargée via loadURL. #47575

Changements majeurs avec rupture de compatibilité​

Supprimé : prise en charge de macOS 11​

macOS 11 (Big Sur) n'est plus supporté par Chromium.

Les anciennes versions d'Electron continueront de fonctionner sur Big Sur, mais macOS 12 (Monterey) ou une version ultérieure sera nécessaire pour exécuter Electron v38.0.0 et les versions supérieures.

Removed: ELECTRON_OZONE_PLATFORM_HINT environment variable​

The default value of the --ozone-platform flag changed to auto.

Electron now runs as a native Wayland app by default when launched in a Wayland session on Linux. Some features and APIs behave differently in Wayland and X11. You can force Electron to run in X11 compatibility mode (Xwayland), like it did in older versions, by appending the flag --ozone-platform=x11.

Removed: plugin-crashed event​

L'événement plugin-crashed a été supprimé de webContents`.

Deprecated: webFrame.routingId property​

The routingId property will be removed from webFrame objects.

Vous devrez utiliser webFrame.frameToken à la place.

Deprecated: webFrame.findFrameByRoutingId(routingId)​

The webFrame.findFrameByRoutingId(routingId) function will be removed.

You should use webFrame.findFrameByToken(frameToken) instead.

Google Summer of Code Concludes​

Our two Google Summer of Code contributors have just completed their summer projects!

• @nilayarya crafted a new Save/Restore Window State API in Electron core. The new APIs will provide a built-in, standardized way to handle window state persistence. See Nilay's original RFC at electron/rfcs#16.
• @hitarth-gg put a lot of hard work into modernizing the long-dormant Devtron extension using Chrome Manifest V3 APIs. This project provides tooling for developers to debug IPC communication, track event listeners, and visualize module dependencies in their Electron applications.

Stay tuned for a more detailed blog post outlining their projects and the outcomes.

Fin du support pour 35.x.y​

Electron 35.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

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

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 37.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Google Summer of Code Begins​

Our two Google Summer of Code contributors have started the program's coding period!

• @nilayarya is crafting a new Save/Restore Window State API in Electron core. The new APIs will provide a built-in, standardized way to handle window state persistence. See Nilay's in-progress RFC at electron/rfcs#16.
• @hitarth-gg is hard at work modernizing the long-dormant Devtron extension using Chrome Manifest V3 APIs. This project will provide tooling for developers to debug IPC communication, track event listeners, and visualize module dependencies in their Electron applications.

It has been an exciting couple of weeks for our GSOC participants, so stay tuned for more updates!

Changements notables​

Coins arrondis: Squircles CSS natifs​

Electron 37 introduces the custom -electron-corner-smoothing CSS property, which allows apps to create smoother rounded corners to match Apple's macOS design language. This feature originally landed in Electron 36, but we felt like it deserved a brighter spotlight.

Exemple avec un lissage d'angle de 100%

Code	Result
.box { width: 128px; height: 128px; border-radius: 24px; -electron-corner-smoothing: 100%; }

Contrairement à la propriété standard border-radius, qui sculpte les coins du quart de cercle à partir d'un rectangle, -electron-corner-smoothing transforme en douceur la courbe vers une forme squircle avec un périmètre continu.

You can adjust the smoothness using values from 0% to 100%, or use the system-ui value to match the operating system's style (60% on macOS and 0% otherwise). This design enhancement can be applied on borders, outlines, and shadows, giving your app a subtle layer of polish.

Changements de la Stack​

• Chromium 138.0.7204.35
  • Nouveau en 138
  • Nouveau en 137
• Node 22.16.0
  • Notes Node 22.16.0
• V8 13.8

Electron 37 met à jour Chromium de 136.0.7103.48 à 138.0.7204.35 et V8 de 13.6 à 13.8.

Nouvelles fonctionnalités et améliorations​

• Added innerWidth and innerHeight options for window.open. #47039 (Également en 35, 36)
• Added before-mouse-event to allow intercepting and preventing mouse events in webContents. #47364 (Également en 36)
• Added scriptURL property to ServiceWorkerMain. #45863
• Added sublabel functionality for menus on macOS >= 14.4. #47042 (Également en 35, 36)
• Added support for HIDDevice.collections. #47483 (Également en 36)
• Added support for --no-experimental-global-navigator flag. #47418 (Également en 35, 36)
• Added support for screen.dipToScreenPoint(point) and screen.screenToDipPoint(point) on Linux X11. #46895 (Également en 35, 36)
• Added support for menu item role palette and header on macOS. #47245
• Added support for node option --experimental-network-inspection. #47031 (Également en 35, 36)
• Exposed win.isContentProtected() to allow developers to check window protection status. #47310 (Également en 36)

Changements majeurs avec rupture de compatibilité​

Modification du comportement en cas de rejet non géré par le processus utilitaire​

Les processus utilitaires affichent désormais un message d'erreur lorsqu'un rejet non géré se produit, au lieu de provoquer le plantage du processus.

Pour rétablir le comportement précédent, vous pouvez utiliser :

process.on('unhandledRejection', () => {
  process.exit(1);
});

Comportement modifié : process.exit() termine l'utilitaire de façon synchronisée​

Calling process.exit() in a utility process will now kill the utility process synchronously. This brings the behavior of process.exit() in line with Node.js behavior.

Please refer to the Node.js docs and PR #45690 to understand the potential implications of that, e.g., when calling console.log() before process.exit().

Changement de comportement : prise en charge de la liste de blocage WebUSB et WebSerial​

WebUSB and Web Serial now support the WebUSB Blocklist and Web Serial Blocklist used by Chromium and outlined in their respective specifications.

To disable these, users can pass disable-usb-blocklist and disable-serial-blocklist as command line flags.

Supprimé: valeur null pour la propriété session dans ProtocolResponse​

Cette fonctionnalité obsolète a été supprimée.

Previously, setting the ProtocolResponse.session property to null would create a random independent session. Ceci n'est plus pris en charge.

Using single-purpose sessions here is discouraged due to overhead costs; however, old code that needs to preserve this behavior can emulate it by creating a random session with session.fromPartition(some_random_string) and then using it in ProtocolResponse.session.

Comportement modifié : BrowserWindow.IsVisibleOnAllWorkspaces() sur Linux​

BrowserWindow.IsVisibleOnAllWorkspaces() will now return false on Linux if the window is not currently visible.

Fin du support pour 34.x.y​

Electron 34.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

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

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 36.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables​

Support des outils d'écriture​

Dans Electron 36, vous pouvez activer les fonctionnalités du système macOS telles que les outils d'écriture (orthographe et grammaire), le remplissage automatique et les éléments de menu Services dans vos menus contextuels. Pour ce faire, passez une instance WebFrameMain dans le paramètre frame de menu.popup().

import { BrowserWindow, Menu, WebFrameMain } from 'electron';

const currentWindow = BrowserWindow.getFocusedWindow();
const focusedFrame = currentWindow.webContents.focusedFrame;
const menu = Menu.buildFromTemplate([{ label: 'Copy', role: 'copy' }]);

menu.popup({
  window: currentWindow,
  frame: focusedFrame,
});

Changements de la Stack​

• Chromium 136.0.7103.48
  • Nouveau en 136
  • [https://developer.chrome.com/blog/new-in-chrome-135)
• Node 22.14.0
  • Node 22.14.0 blog post
• V8 13.6

Electron 36 met à jour Chromium de 134.0.6998.23 à 136.0.7103.48 et V8 de 13.5 à 13.6.

Nouvelles fonctionnalités et améliorations​

• Ajout de "BrowserWindow.isSnapped()" pour indiquer si une fenêtre donnée a été disposée par Snap sur Windows. #46226
• Ajout de WebContents.focusedFrame pour obtenir la frame ciblée.
• Correction de WebContents.opener pour spécifier le type potentiel null. #45667
• Ajout de ffmpeg.dll pour retarder la configuration de chargement. #46173 (Également en 34, 35)
• Ajout de nativeTheme.shouldUseDarkColorsForSystemIntegratedUI pour distinguer le thème du système et de l'application. #46598 (Également en 35)
• Ajout de excludeUrls au filtre webRequest et dépréciation de l'utilisation de tableaux vides dans la propriété urls. #44692 (Également en 35)
• Added support for Autofill, Writing Tools and Services macOS level menu items in context menus via the new frame option in menu.popup. #46350
• Added support for system-context-menu on Linux. #46399
• Improved ASAR integrity checks on Windows. #46537
• Improved performance of desktopCapturer.getSources when not requesting thumbnails on macOS. #46251 (Également en 34, 35)
• Removed 240 FPS limit when using shared texture OSR. #45669 (Également en 35)

Changements majeurs avec rupture de compatibilité​

Obsolète : NativeImage.getBitmap()​

The NativeImage.getBitmap() function is now deprecated and documented as an alias for NativeImage.toBitmap(). The two functions both return a newly-allocated copy of the bitmap and are functionally equivalent.

Obsolète: Méthodes d'extension et événements sur session​

session.loadExtension’, ‘session.removeExtension’, ‘session.getExtension’, ‘session.getAllExtensions’, et les événements extension-loaded’, extension-déchargée’, et extension-ready’' ont tous déménagé dans le nouveau Extensions object accessible par l’intermédiaire de la propriété d'instance session.extensions.

Supprimé: quota type syncable dans session.clearStorageData(options)​

When calling session.clearStorageData(options), the options.quota type syncable is no longer supported because it has been removed from upstream Chromium.

Deprecated: quota property in session.clearStorageData(options)​

When calling Session.clearStorageData(options), the options.quota property is deprecated. Since the syncable type was removed, there is only type left -- 'temporary' -- so specifying it is unnecessary.

Comportement modifié : GTK 4 est la valeur par défaut lors de l'exécution sur GNOME​

After an upstream change, GTK 4 is now the default when running on GNOME.

In rare cases, this may cause some applications or configurations to error with the following message:

Gtk-ERROR **: 11:30:38.382: GTK 2/3 symbols detected. Using GTK 2/3 and GTK 4 in the same process is not supported

Affected users can work around this by specifying the gtk-version command-line flag:

$ electron --gtk-version=3   # or --gtk-version=2

The same can be done with the app.commandLine.appendSwitch function.

Changements de comportement : app.commandLine​

app.commandLine will convert uppercases switches and arguments to lowercase.

app.commandLine was only meant to handle Chromium switches (which aren't case-sensitive) and switches passed via app.commandLine will not be passed down to any of the child processes.

If you were using app.commandLine to parse app-specific command line arguments, you should do this via process.argv.

Fin du support pour 33.x.y​

Electron 33.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

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

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 35.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables​

Scripts de Service Worker Preload pour une prise en charge améliorée des extensions​

Originally proposed in RFC #8 by @samuelmaddock, Electron 35 adds the ability to attach a preload script to Service Workers. With Chrome's Manifest V3 Extensions routing a lot of work through extension service workers, this feature fills in a gap in Electron's support for modern Chrome extensions.

When registering a preload script programmatically at the Session level, you can now specifically apply it to Service Worker contexts with the ses.registerPreloadScript(script) API.

// Add our preload realm script to the session.
session.defaultSession.registerPreloadScript({
  // Our script should only run in service worker preload realms.
  type: 'service-worker',
  // The absolute path to the script.
  script: path.join(__dirname, 'extension-sw-preload.js'),
});

De plus, l'IPC est maintenant disponible entre les Service Workers et leurs scripts de préchargement via la classe ServiceWorkerMain.ipc. The preload script will still use the ipcRenderer module to communicate with its Service Worker. See the original RFC for more details.

This feature was preceded by many other changes that laid the groundwork for it:

• #45329 redesigned the Session module's preload APIs to support registering and unregistering individual preload scripts.
• #45229 added the experimental contextBridge.executeInMainWorld(executionScript) script to evaluate JavaScript in the main world over the context bridge.
• #45341 added the ServiceWorkerMain class to interact with Service Workers in the main process.

Changements de la Stack​

• Chromium 134.0.6998.44
  • Nouveau en 134
  • Nouveau en 133
• Node 22.14.0
  • Node 22.14.0 blog post
• V8 13.5

Electron 35 upgrades Chromium from 132.0.6834.83 to 134.0.6998.44, Node from 20.18.1 to 22.14.0, and V8 from 13.2 to 13.5.

Nouvelles fonctionnalités​

• Added NSPrefersDisplaySafeAreaCompatibilityMode = false to Info.plist to remove "Scale to fit below built-in camera." from app options. #45357 ^{(Also in v34.1.0)}
• Added ServiceWorkerMain class to interact with service workers in the main process. #45341
  • Added running-status-changed event on ServiceWorkers to indicate when a service worker's running status has changed.
  • Added startWorkerForScope on ServiceWorkers to start a worker that may have been previously stopped.
• Added experimental contextBridge.executeInMainWorld to safely execute code across world boundaries. #45330
• Added frame to 'console-message' event. #43617
• Added query-session-end event and improved session-end events on Windows. #44598
• Added view.getVisible(). #45409
• Added webContents.navigationHistory.restore(index, entries) API that allows restoration of navigation history. #45583
• Added optional animation parameter to BrowserWindow.setVibrancy. #35987
• Added permission support for document.executeCommand("paste"). #45471 ^{(Also in v34.1.0)}
• Added support for roundedCorners BrowserWindow constructor option on Windows. #45740 ^{(Also in v34.3.0)}
• Added support for service worker preload scripts. #45408
• Support Portal's globalShortcuts. Electron must be run with --enable-features=GlobalShortcutsPortal in order to have the feature working. #45297

Changements majeurs avec rupture de compatibilité​

Removed: isDefault and status properties on PrinterInfo​

These properties have been removed from the PrinterInfo object because they have been removed from upstream Chromium.

Deprecated: getFromVersionID on session.serviceWorkers​

The session.serviceWorkers.fromVersionID(versionId) API has been deprecated in favor of session.serviceWorkers.getInfoFromVersionID(versionId). This was changed to make it more clear which object is returned with the introduction of the session.serviceWorkers.getWorkerFromVersionID(versionId) API.

// Deprecated
session.serviceWorkers.fromVersionID(versionId);

// Replace with
session.serviceWorkers.getInfoFromVersionID(versionId);

Deprecated: setPreloads, getPreloads on Session​

registerPreloadScript, unregisterPreloadScript, and getPreloadScripts are introduced as a replacement for the deprecated methods. These new APIs allow third-party libraries to register preload scripts without replacing existing scripts. Also, the new type option allows for additional preload targets beyond frame.

// Deprecated
session.setPreloads([path.join(__dirname, 'preload.js')]);

// Replace with:
session.registerPreloadScript({
  type: 'frame',
  id: 'app-preload',
  filePath: path.join(__dirname, 'preload.js'),
});

Deprecated: level, message, line, and sourceId arguments in console-message event on WebContents​

The console-message event on WebContents has been updated to provide details on the Event argument.

// Deprecated
webContents.on(
  'console-message',
  (event, level, message, line, sourceId) => {},
);

// Replace with:
webContents.on(
  'console-message',
  ({ level, message, lineNumber, sourceId, frame }) => {},
);

Additionally, level is now a string with possible values of info, warning, error, and debug.

Behavior Changed: urls property of WebRequestFilter.​

Previously, an empty urls array was interpreted as including all URLs. To explicitly include all URLs, developers should now use the <all_urls> pattern, which is a designated URL pattern that matches every possible URL. This change clarifies the intent and ensures more predictable behavior.

// Deprecated
const deprecatedFilter = {
  urls: [],
};

// Replace with
const newFilter = {
  urls: ['<all_urls>'],
};

Deprecated: systemPreferences.isAeroGlassEnabled()​

The systemPreferences.isAeroGlassEnabled() function has been deprecated without replacement. It has been always returning true since Electron 23, which only supports Windows 10+, where DWM composition can no longer be disabled.

https://learn.microsoft.com/en-us/windows/win32/dwm/composition-ovw#disabling-dwm-composition-windows7-and-earlier

Fin du support pour 32.x.y​

Electron 32.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

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

Pour plus d'informations sur le programme, rendez-vous sur la page d'accueil Google Summer of Code (https://summerofcode.withgoogle.com/).

À propos de nous​

Electron est un framework JavaScript pour la construction d'applications de bureau multi-plateformes en utilisant les technologies web. Le framework cœur d'Electron est un exécutable binaire compilé avec Chromium et Node.js, et est principalement écrit en C++.

En dehors du référentiel central Electron, nous gérons également plusieurs projets visant à soutenir l'écosystème Electron, notamment :

• Outils pour la distribution aux utilisateurs finaux (par exemple Electron Forge et update.electronjs.org).
• Supports pédagogiques pour les développeurs Electron (par exemple electronjs.org et Electron Fiddle).
• Outils internes pour améliorer la productivité des développeurs (par exemple, Electron Build Tools et Sheriff).

En tant que contributeur GSoC, vous aurez l'occasion de collaborer avec certains des principaux contributeurs d'Electron sur l'un des nombreux projets sous l'égide de github.com/electron.

Avant la demande​

Si vous n'êtes pas très familier avec Electron, nous vous recommandons de commencer par lire la documentation et d'essayer certains des exemples proposés dans Electron Fiddle.

Pour en savoir plus sur la distribution des applications Electron, essayez de créer un exemple d'application avec Electron Forge :

npm init electron-app@latest my-app

Après vous être familiarisé un peu avec le code, venez rejoindre la conversation sur le serveur Discord Electron.

Contributions au projet​

Nous vous encourageons à consulter tous les référentiels pertinents pour les idées de projet qui vous intéressent . Une façon de mener vos recherches consiste à contribuer en signalant des bogues, en triant les problèmes existants ou en soumettant des demandes d'extraction. Cela constitue un moyen efficace d'acquérir une expérience pratique de nos bases de code, mais n'est pas obligatoire pour soumettre une proposition. Une proposition bien rédigée devrait permettre de démontrer votre compréhension du code sans avoir besoin de se référer à des contributions antérieures.

Voici quelques conseils si vous souhaitez contribuer à Electron avant de soumettre votre proposition :

1. Veuillez fournir une description détaillée du problème ou des relations publiques lorsque vous soumettez vos contributions. Indépendamment du code lui-même, le fait de consacrer des efforts à la partie écrite d'une contribution nous montre que vous pouvez être un communicateur efficace dans un environnement collaboratif.
2. Les relecteurs sont toujours les bienvenus pour les questions en suspens. Vous n'avez pas besoin de commenter un problème en demandant à un responsable si vous pouvez être affecté à celui-ci. Notez que nous vous encourageons toujours à discuter des solutions potentielles sur un problème si vous avez besoin d'affiner une idée de solution, mais les commentaires qui demandent uniquement si vous pouvez travailler sur quelque chose sont redondants et ajoutent du superflu au suivi des problèmes.
3. Les contributions au projet nécessitant peu d'efforts (par exemple, les rapports d'erreurs non valides, les modifications mineures de la formulation dans un fichier README du dépôt ou les modifications stylistiques mineures du code frontal) auront un impact négatif sur votre proposition finale, car elles mobilisent le temps limité des responsables de la maintenance et n'apportent aucun avantage net au projet Electron.
4. Bien que les assistants de codage IA puissent être un outil efficace pour le débogage et la compréhension de nouveaux concepts, nous déconseillons fortement les contributions copiées/collées directement à partir d'une sortie générée par l'IA. Ces derniers s'avèrent souvent de mauvaise qualité, et cela demande souvent plus d'efforts aux responsables de la maintenance pour nettoyer le code généré à partir d'un LLM que pour nous de simplement rejeter une PR.

Rédiger votre proposition​

Êtes-vous intéressé à collaborer avec Electron? Tout d'abord, consultez les sept projets d'idées que nous avons préparés. Toutes les idées énumérées sont ouvertes aux propositions.

Si vous avez une idée originale qui ne figure pas dans la liste, nous sommes disposés à l'examiner, mais veillez à ce que votre proposition soit détaillée et bien structurée. En cas de doute, nous vous recommandons de vous en tenir à nos idées énumérées.

Votre candidature devra inclure :

• Une proposition détaillée décrivant ce que vous prévoyez accomplir au cours de l'été.
• Votre expérience en tant que développeur. Si vous avez un curriculum vitae, veuillez en inclure une copie. Sinon, parlez-nous de votre expérience technique passée.
  • Le manque d'expérience dans certains domaines ne vous disqualifiera pas, mais cela aidera nos mentors à élaborer un plan pour vous soutenir au mieux et garantir la réussite de votre projet d'été.

Vous trouverez ici un guide détaillé sur les documents à fournir dans le cadre de votre demande Electron. Soumettez vos propositions directement sur le portail Google Summer of Code. Les propositions envoyées par e-mail à l'équipe Electron ne seront pas considérées comme des soumissions définitives.

Pour plus d'informations sur votre proposition, nous vous recommandons de suivre les conseils officiels de Google Summer of Code pour la rédaction de propositions ici.

Les candidatures sont ouvertes du 24 mars 2025 au 8 avril 2025.

Questions?​

Si vous avez des questions auxquelles nous n'avons pas répondu dans cet article ou des demandes concernant votre projet de proposition, veuillez nous envoyer un e-mail à summer-of-code@electronjs.org ou consulter la FAQ GSoC. Veuillez lire notre guide à l'intention des contributeurs avant d'envoyer votre e-mail.

Ressources​

• Liste d'idées pour le Google Summer of Code 2025 d'Electron
• Guide du contributeur au programme Google Summer of Code 2025 d'Electron
• Google Summer of Code Student/Contributeur Guide

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 34.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables​

HTTP Compression Shared Dictionary Management APIs​

HTTP compression allows data to be compressed by a web server before being received by the browser. Modern versions of Chromium support Brotli and Zstandard, which are newer compression algorithms that perform better for text files than older schemes such as gzip.

Custom shared dictionaries further improve the efficiency of Brotli and Zstandard compression. See the Chrome for Developers blog on shared dictionaries for more information.

@felixrieseberg added the following APIs in #44950 to manage shared dictionaries at the Session level:

• session.getSharedDictionaryUsageInfo()
• session.getSharedDictionaryInfo(options)
• session.clearSharedDictionaryCache()
• session.clearSharedDictionaryCacheForIsolationKey(options)

Unresponsive Renderer JavaScript Call Stacks​

Electron's unresponsive event occurs whenever a renderer process hangs for an excessive period of time. The new WebFrameMain.collectJavaScriptCallStack() API added by @samuelmaddock in #44204 allows you to collect the JavaScript call stack from the associated WebFrameMain object (webContnets.mainFrame).

This API can be useful to determine why the frame is unresponsive in cases where there's long-running JavaScript events causing the process to hang. For more information, see the proposed web standard Crash Reporting API.

const { app } = require('electron');

app.commandLine.appendSwitch(
  'enable-features',
  'DocumentPolicyIncludeJSCallStacksInCrashReports',
);

app.on('web-contents-created', (_, webContents) => {
  webContents.on('unresponsive', async () => {
    // Interrupt execution and collect call stack from unresponsive renderer
    const callStack = await webContents.mainFrame.collectJavaScriptCallStack();
    console.log('Renderer unresponsive\n', callStack);
  });
});

Changements de la Stack​

• Chromium 132.0.6834.83
  • Nouveau en 131
  • Nouveau en 132
• Node 20.18.1
  • Node 20.18.1 blog post
• V8 13.2

Electron 34 upgrades Chromium from 130.0.6723.44 to 132.0.6834.83, Node from 20.18.0 to 20.18.1, and V8 from 13.0 to 13.2.

Nouvelles fonctionnalités​

• Added APIs to manage shared dictionaries for compression efficiency using Brotli or ZStandard. The new APIs are session.getSharedDictionaryUsageInfo(), session.getSharedDictionaryInfo(options), session.clearSharedDictionaryCache(), and session.clearSharedDictionaryCacheForIsolationKey(options). #44950
• Added WebFrameMain.collectJavaScriptCallStack() for accessing the JavaScript call stack of unresponsive renderers. #44938
• Added WebFrameMain.detached for frames in an unloading state.
  • Added WebFrameMain.isDestroyed() to determine if a frame has been destroyed.
  • Fixed webFrameMain.fromId(processId, frameId) returning a WebFrameMain instance which doesn't match the given parameters when the frame is unloading. #43473
• Ajout d'un événement d'erreur dans le processus utilitaire pour supporter les rapports de diagnostic sur les erreurs fatales V8. #43774
• Feat: GPU accelerated shared texture offscreen rendering. #42953

Changements majeurs avec rupture de compatibilité​

Behavior Changed: menu bar will be hidden during fullscreen on Windows​

This brings the behavior to parity with Linux. Prior behavior: Menu bar is still visible during fullscreen on Windows. New behavior: Menu bar is hidden during fullscreen on Windows.

Correction: This was previously listed as a breaking change in Electron 33, but was first released in Electron 34.

Fin du support pour 31.x.y​

Electron 31.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

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

Qu’est-ce que ça signifie ?​

Dans le passé, les paquets dans l'écosystème npm d'Electron (Forge, Packager, etc) ont pris en charge les versions de Node aussi longtemps que possible, même une fois qu'une version a atteint sa date de fin de vie (EOL) . Ceci pour s'assurer que nous ne fragmentons pas l'écosystème - nous comprenons bien que de nombreux projets dépendent des anciennes versions de Node, et nous ne voulons pas risquer de bloquer ces projets à moins qu’il y ait une raison pressante de les améliorer.

Avec le temps, l'utilisation de Node.js 14 comme notre version minimale est devenue de plus en plus difficile pour quelques raisons :

• Le manque de versions officielles de Node.js 14 pour macOS ARM64 nous oblige à maintenir des solutions d'infrastructure de CI pour fournir une couverture de test complète.
• engines requirements for upstream package dependencies have moved forward, making it increasingly difficult to resolve supply chain security issues with dependency bumps.

Additionally, newer versions of Node.js have included many improvements that we would like to leverage, such as runtime-native common utilities (e.g. fs.glob and util.parseArgs) and entire new batteries-included modules (e.g. node:test, node:sqlite).

Pourquoi mettre à niveau maintenant ?​

In July 2024, Electron’s Ecosystem Working Group decided to upgrade all packages to the earliest Node version where require()of synchronous ESM graphs will be supported (see nodejs/node#51977 and nodejs/node#53500) at a future point after that version reaches its LTS date.

Nous avons décidé d'effectuer cette de mise à jour en Janvier/Février 2025. Après cette mise à jour, Node 22 sera la version minimale supportée dans les paquets écosystèmes existants.

Quelles mesures devrais-je prendre ?​

Nous nous efforcerons de maintenir la compatibilité autant que possible. Cependant, pour assurer le meilleur support possible, nous vous encourageons à mettre à jour vos applications vers Node 22 ou plus.

Notez que la version de Node exécutée dans votre projet n'est pas liée à la version de Node embarquée dans votre version actuelle d'Electron.

Et pour la suite​

N'hésitez pas à nous joindre sur info@electronjs.org](mailto:info@electronjs.org si vous avez des questions ou des préoccupations. Vous pouvez également obtenir le support de la communauté sur notre Discord Electron.

via GIPHY

Ce qui ne changera pas en Décembre​

1. Les versions zero-day et autres versions majeures liées à la sécurité seront publiées si nécessaire. Les incidents de sécurité doivent être signalés via SECURITY.md.
2. Les rapports du Code de conduite et la modération se poursuivront normalement.

Ce qui sera différent en Décembre​

1. Les dernières versions de la branche stable de l'année 2024, dont Electron 31, 32 et 33, auront lieu la semaine du 1er décembre. Il n'y aura pas de nouvelles sorties prévues en décembre.
2. Pas de sorties Nightly et Alpha pour les deux dernières semaines de décembre.
3. À quelques exceptions près, il n'y aura pas de ré-éxamen de pull request ni de merge.
4. Aucune mise à jour de suivi de tickets sur aucun dépôt.
5. Aucune aide de débogage de la part des mainteneurs sur Discord.
6. Aucune mise à jour du contenu des réseaux sociaux.

On se revoit en 2025!

Electron is moving from BrowserView to WebContentsView to align with Chromium’s UI framework, the Views API. WebContentsView offers a reusable view directly tied to Chromium’s rendering pipeline, simplifying future upgrades and opening up the possibility for developers to integrate non-web UI elements to their Electron apps. By adopting WebContentsView, applications are not only prepared for upcoming updates but also benefit from reduced code complexity and fewer potential bugs in the long run.

Developers familiar with BrowserWindows and BrowserViews should note that BrowserWindow and WebContentsView are subclasses inheriting from the BaseWindow and View base classes, respectively. To fully understand the available instance variables and methods, be sure to consult the documentation for these base classes.

Migration steps​

1. Upgrade Electron to 30.0.0 or higher​

2. Familiarize yourself with where your application uses BrowserViews​

One way to do this is to search your codebase for new BrowserView(. This should give you a sense for how your application is using BrowserViews and how many call sites need to be migrated.

3. Migrate each usage of BrowserView​

1. Migrate the instantiation. This should be fairly straightforward because WebContentsView and BrowserView’s constructors have essentially the same shape. Both accept WebPreferences via the webPreferences param.

   - this.tabBar = new BrowserView({
   + this.tabBar = new WebContentsView({
   

   info

   By default, WebContentsView instantiates with a white background, while BrowserView instantiates with a transparent background. To get a transparent background in WebContentsView, set its background color to an RGBA hex value with an alpha (opaqueness) channel set to 00:

   + this.webContentsView.setBackgroundColor("#00000000");
   

2. Migrate where the BrowserView gets added to its parent window.

   - this.browserWindow.addBrowserView(this.tabBar)
   + this.browserWindow.contentView.addChildView(this.tabBar);
   

3. Migrate BrowserView instance method calls on the parent window.

   Old Method	New Method	Remarques
   win.setBrowserView	win.contentView.removeChildView + win.contentView.addChildView
   win.getBrowserView	win.contentView.children
   win.removeBrowserView	win.contentView.removeChildView
   win.setTopBrowserView	win.contentView.addChildView	Calling addChildView on an existing view reorders it to the top.
   win.getBrowserViews	win.contentView.children

4. Migrate the setAutoResize instance method to a resize listener.

   - this.browserView.setAutoResize({
   -   vertical: true,
   - })
   
   + this.browserWindow.on('resize', () => {
   +   if (!this.browserWindow || !this.webContentsView) {
   +     return;
   +   }
   +   const bounds = this.browserWindow.getBounds();
   +   this.webContentsView.setBounds({
   +     x: 0,
   +     y: 0,
   +     width: bounds.width,
   +     height: bounds.height,
   +    });
   +  });
   

   astuce

   All existing usage of browserView.webContents and instance methods browserView.setBounds, browserView.getBounds , and browserView.setBackgroundColor do not need to be migrated and should work with a WebContentsView instance out of the box!

4) Test and commit your changes​

Running into issues? Check the WebContentsView tag on Electron's issue tracker to see if the issue you're encountering has been reported. If you don't see your issue there, feel free to add a new bug report. Including testcase gists will help us better triage your issue!

Congrats, you’ve migrated onto WebContentsViews! 🎉

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 33.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

Si vous avez des commentaires, veuillez les partager avec nous sur [Twitter] (https://twitter.com/electronjs) ou Mastodon, ou joignez-vous à notre communauté [Discord] (https://discord.com/invite/electronjs)! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables​

• Ajout d'un gestionnaire, app.setClientCertRequestPasswordHandler(handler), pour faciliter le déverrouillage des périphériques cryptographiques quand un code PIN est nécessaire. #41205
• Extended navigationHistory API with 2 new functions for better history management. #42014
• Improved native theme transparency checking. #42862

Changements de la Stack​

• Chromium 130.0.6723.44
  • New in 130
  • New in 129
• Node 20.18.0
  • Node 20.18.0 blog post
  • Node 20.17.0 blog post
• V8 13.0

Electron 33 upgrades Chromium from 128.0.6613.36 to 130.0.6723.44, Node from 20.16.0 to 20.18.0, and V8 from 12.8 to 13.0.

Nouvelles fonctionnalités​

• Ajout d'un gestionnaire, app.setClientCertRequestPasswordHandler(handler), pour faciliter le déverrouillage des périphériques cryptographiques quand un code PIN est nécessaire. #41205
• Ajout d'un événement d'erreur dans le processus utilitaire pour supporter les rapports de diagnostic sur les erreurs fatales V8. #43997
• Ajout de View.setBorderRadius(radius) pour personnaliser le rayon de bordure des vues, pour être compatible avec WebContentsView. #42320
• Extended navigationHistory API with 2 new functions for better history management. #42014

Changements majeurs avec rupture de compatibilité​

Removed: macOS 10.15 support​

macOS 10.15 (Catalina) is no longer supported by Chromium.

Older versions of Electron will continue to run on Catalina, but macOS 11 (Big Sur) or later will be required to run Electron v33.0.0 and higher.

Behavior Changed: Native modules now require C++20​

Due to changes made upstream, both V8 and Node.js now require C++20 as a minimum version. Les développeurs qui utilisent des modules natifs de node devraient compiler leurs modules avec --std=c++20 plutôt que --std=c++17. Les images utilisant gcc9 ou inférieur peuvent avoir besoin de se mettre à jour vers gcc10 pour compiler. See #43555 for more details.

Behavior Changed: custom protocol URL handling on Windows​

Due to changes made in Chromium to support Non-Special Scheme URLs, custom protocol URLs that use Windows file paths will no longer work correctly with the deprecated protocol.registerFileProtocol and the baseURLForDataURL property on BrowserWindow.loadURL, WebContents.loadURL, and <webview>.loadURL. protocol.handle will also not work with these types of URLs but this is not a change since it has always worked that way.

// No longer works
protocol.registerFileProtocol('other', () => {
  callback({ filePath: '/path/to/my/file' });
});

const mainWindow = new BrowserWindow();
mainWindow.loadURL(
  'data:text/html,<script src="loaded-from-dataurl.js"></script>',
  { baseURLForDataURL: 'other://C:\\myapp' },
);
mainWindow.loadURL('other://C:\\myapp\\index.html');

// Replace with
const path = require('node:path');
const nodeUrl = require('node:url');
protocol.handle(other, (req) => {
  const srcPath = 'C:\\myapp\\';
  const reqURL = new URL(req.url);
  return net.fetch(
    nodeUrl.pathToFileURL(path.join(srcPath, reqURL.pathname)).toString(),
  );
});

mainWindow.loadURL(
  'data:text/html,<script src="loaded-from-dataurl.js"></script>',
  { baseURLForDataURL: 'other://' },
);
mainWindow.loadURL('other://index.html');

Comportement modifié : propriété webContents sur login sur app​

The webContents property in the login event from app will be null when the event is triggered for requests from the utility process created with respondToAuthRequestsFromMainProcess option.

Deprecated: textured option in BrowserWindowConstructorOption.type​

The textured option of type in BrowserWindowConstructorOptions has been deprecated with no replacement. This option relied on the NSWindowStyleMaskTexturedBackground style mask on macOS, which has been deprecated with no alternative.

Deprecated: systemPreferences.accessibilityDisplayShouldReduceTransparency​

The systemPreferences.accessibilityDisplayShouldReduceTransparency property is now deprecated in favor of the new nativeTheme.prefersReducedTransparency, which provides identical information and works cross-platform.

// Deprecated
const shouldReduceTransparency =
  systemPreferences.accessibilityDisplayShouldReduceTransparency;

// Replace with:
const prefersReducedTransparency = nativeTheme.prefersReducedTransparency;

Fin du support pour 30.x.y​

Electron 30.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

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

Bonjour 👋, je suis Peter, le contributeur Electron pour le Google Summer of Code (GSoC).

Over the course of the GSoC program, I implemented an API history feature for the Electron documentation and its functions, classes, etc. in a similar fashion to the Node.js documentation: by allowing the use of a simple but powerful YAML schema in the API documentation Markdown files and displaying it nicely on the Electron documentation website.

Détails​

Système de documentation de l’API / schéma YAML​

In the Markdown API documentation, the history for a function/class/etc. is now placed directly after the header for that item in the form of a YAML code block encapsulated by an HTML comment.

#### `win.setTrafficLightPosition(position)` _macOS_

<!--
```YAML history
added:
  - pr-url: https://github.com/electron/electron/pull/22533
changes:
  - pr-url: https://github.com/electron/electron/pull/26789
    description: "Made `trafficLightPosition` option work for `customButtonOnHover` window."
deprecated:
  - pr-url: https://github.com/electron/electron/pull/37094
    breaking-changes-header: deprecated-browserwindowsettrafficlightpositionposition
```
-->

* `position` [Point](structures/point.md)

Set a custom position for the traffic light buttons. Can only be used with `titleBarStyle` set to `hidden`.

I believe using YAML like the Node.js docs do was the best approach because it is easy to read. The API history isn't extremely complicated and should ideally be as easy to write and read as possible.

The final design shown above is actually significantly different to the one I proposed:

<!--
```YAML history
added: v10.0.0
deprecated: v25.0.0
removed: v28.0.0
changes:
  - version: v13.0.0
    pr-url: https://github.com/electron/electron/pull/26789
    description: Made `trafficLightPosition` option work for `customButtonOnHover` window.
```
-->

Un changement important est la suppression des numéros de version:

"[...] There’s one somewhat significant change we’d like to call out about the proposal, which came up during discussion when we were reviewing proposals. [...]

[we] decided that the approach with the [fewest] drawbacks would be to only use PR URLs (the root PRs to main) instead of hardcoded version strings as in the proposal.

This can serve as a single source of truth which can then be used to derive exact version numbers, and no further documentation changes on main are necessary if the change is backported to other branches."

— David Sanders (@dsanders11) via Slack

Nous n’avons pas non plus inclus les suppressions dans l’historique des APIs, car lorsqu’une API est supprimée d'Electron, elle est également supprimée de la documentation.

Implémentation JavaScript​

J'avais initialement prévu de créer un nouveau package npm @electron/docs-api-history-tools contenant des scripts pour extraire, valider/lint et faire la conversion de l'historique de l'API dans les fichiers de documentation.

Mais environ une semaine avant le début de la période de codage, et après une discussion avec mes mentors , j'ai réalisé que c'était probablement inutile:

"Hi everyone, I was thinking about the project after our huddle: Considering that extraction logic will have to be handled differently in e/website and e/lint-roller because of their dependencies, maybe there is no need for a separate package for API history stuff?"

Proposed	Revised

— Piotr Płaczek (me) via Slack

Nous avons finalement décidé de ne pas suivre mon idée initiale:

"@Piotr Płaczek that seems fine to me! I think we can always refactor out to a separate module in a later iteration if we find that we need to share a lot of code between the two implementations anyways 🙂"

— Erick Zhao (@erickzhao) via Slack

Instead, we divided those various tools across the Electron repos that were most relevant to them:

• yaml-api-history-schema.json
  • -> electron/electron (api-history.schema.json)
• lint-yaml-api-history.ts
  • -> electron/lint-roller (lint-markdown-api-history.ts)
• extract-yaml-api-history.ts
  • -> electron/website (preprocess-api-history.ts)
• yaml-api-history-to-markdown.ts
  • -> electron/website (transformers/api-history.ts)
  • -> electron/website (ApiHistoryTable.tsx)

Interface utilisateur et style pour le site web de documentation d'Electron​

J'ai proposé à l'origine une table simple pour afficher les données de l'historique de l'API :

Prototype de design (Fermé)	Prototype de conception (Ouvert)

Et voici à quoi ressemble la conception finale:

C'est à peu près la même chose que le prototype. L'ajout le plus significatif est l'utilisation des plages de SemVer, qui ont été choisies pour mieux communiquer dans quelles versions une fonctionnalité est présente (merci Samuel Attard (@MarshallOfSound) pour la suggestion !).

C'est important parce que les changements sont fréquemment rétroportés sur les lignes de publication prises en charge par Electron. , un correctif peut le rendre dans Electron v32.0.0, v31.1.0 et v30.2.0. Cela signifie qu'il n'est pas présent dans la v31.0. dont un utilisateur peut déduire par erreur sur la base du fait qu'il est présent dans une version v30.x.x.

Guide d'utilisation et de style​

J’ai ajouté un guide d’utilisation/style dédié à la rédaction de documentation sur l’historique des API pour les nouvelles fonctionnalités. J’y décrit en détail les usages propres du schéma YAML, accompagné d'exemples typiques/utiles, etc. Vous pouvez le trouver here.

Guide de migration​

Since existing APIs have to be migrated to the new documentation system, I created a migration guide. It features the typical steps of what a developer has to do when migrating old APIs: looking through breaking changes, browsing through the past releases, maybe looking through old commits, etc. Then instructing the developer to follow the usage/style guide to add API history documentation for each previously existing class/function/etc.

Sadly, I couldn't think of a way to automate this effectively. This would probably be a great task for an AI/ML engineer; however, I don't possess those skills and was too afraid of accidentally introducing hallucinations into the API history. Even if automated, the information would still probably have to be verified by a human in the end 😕. This task will probably have to be done manually, on a file-by-file basis, just like it was done for the Node.js documentation.

Déliverables​

• api-history.schema.json

  • Un schéma YAML complet pour la documentation de l'historique de l'API incluant le support pour:
    • Additions
    • Deprecations
    • Changements
    • Liens vers les pull requests pertinentes
    • Rétroportages
  • Proposé dans: electron/rfc#6
  • Implementé/Utilisé dans: electron/electron#42982
  • Utilisé dans: electron/website#594

• lint-markdown-api-history.ts

  • Script pour lintin de lhistorique de l''API YAML ecrit selon un schéma YAML (techniquement JSON).
    • Messages d'erreur utiles
    • Documentation complète / commentaires de code
    • Tests détaillés ~~~Jest~~ Vitest
    • Bonne performance
  • Implémenté dans: electron/lint-roller#73
  • Utilisé dans: electron/electron#42982

• preprocess-api-history.ts

  • Performs simple validation just in case incorrect API History manages to make it into the repo. Also strips the HTML comment tags that wrap API History blocks since Docusaurus cannot parse them.
  • Implemented/Used in: electron/website#594

• transformers/api-history.ts

  • Script for converting YAML API history blocks in the Markdown documentation files to Markdown/HTML React tables (ApiHistoryTable.tsx).
  • Implemented/Used in: electron/website#594

• ApiHistoryTable.tsx

  • React table component used to display parsed API History data on the documentation website.
    • Uses styling that follows the rest of the website's design.
    • Responsive, accessible, and generally well written HTML, CSS, and JS.
  • Implemented/Used in: electron/website#594

• styleguide.md

  • Usage/style guide section for new API history documentation system.
    • Easy to understand
    • Well written
    • Includes examples
  • Implementé/Utilisé dans: electron/electron#42982

• api-history-migration-guide.md

  • Migration guide for new API history documentation system.
    • Easy to understand
    • Well written
    • Includes examples
  • Implementé/Utilisé dans: electron/electron#42982

Conclusion​

J'ai eu beaucoup de plaisir à travailler sur cette fonctionnalité et j'ai pu gagner une expérience précieuse grâce aux commentaires de code et à la discussion de ses divers détails d'implémentation avec l'équipe.

Je pense que l'ajout de l'historique de l'API à la documentation rendra la vie de développeurs utilisant Electron beaucoup plus facile, surtout ceux qui tentent de migrer leur application existante depuis une version d'Electron vieille de plusieurs années.

Je tiens également à remercier sincèrement mes mentors:

• David Sanders (@dsanders11)
• Keeley Hammond (@VerteDinde)
• Erick Zhao (@erickzhao)

...et le reste de l'équipe Electron pour avoir répondu à mes questions et avoir pris le temps de me donner des commentaires sur mes pull requests. It is very much appreciated.

L’équipe d'Electron est heureuse d’annoncer la sortie d’Electron 32.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

Si vous avez des commentaires, veuillez les partager avec nous sur [Twitter] (https://twitter.com/electronjs) ou Mastodon, ou joignez-vous à notre communauté [Discord] (https://discord.com/invite/electronjs)! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables​

• Ajout d'un nouvel historique de version de l'API dans notre documentation, une fonctionnalité créée par @piotrpdev dans le cadre de Google Summer of Code. Vous pouvez en savoir plus à ce sujet dans cet article de blog. #42982
• Suppression de l'extension File.\path non standard de l'API Web File. #42053
• #42993
• Ajout des API existantes suivantes liées à la navigation à webcontents.navigationHistory: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear. Les API de navigation précédentes est désormais obsolète. #41752

Changements de la Stack​

• Chromium 128.0.6613.36
  • Nouveau en 128
  • Nouveau en 127
• Node 20.16.0
  • Blog de publication de Node 20.16.0
• V8 12.8

Electron 32 met à jour Chromium de 126.0.6478.36 à 128.0.6613.36, Node de 20.14.0 à 20.16.0, et V8 de 12.6 à 12.8.

Nouvelles fonctionnalités​

• Ajout d'une prise en charge pour répondre aux requêtes d'authentification initiées par le processus utilitaire via l'événement de 'connexion' du module app. #43317
• Ajout de la propriété cumulativeCPUUsage à la structure CPUUsage, qui retourne le total de secondes du temps CPU utilisé depuis le démarrage du processus. #41819
• Ajout des API existantes suivantes liées à la navigation à webContents.navigationHistory: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear. #41752
• Extension de WebContentsView pour accepter les objets webContentspréexistants. #42086
• Ajout d'une nouvelle propriété prefersReducedTransparency à nativeTheme, qui indique si l'utilisateur a choisi de réduire la transparence au niveau du système d'exploitation via les paramètres d'accessibilité du système. #43137
• . #42993
• Activation de l'API Windows Control Overlay sur Linux. #42681
• Activation de la compression zstd dans les requêtes réseau. #43300

Changements majeurs avec rupture de compatibilité​

Supprimé: File.path​

The nonstandard path property of the Web File object was added in an early version of Electron as a convenience method for working with native files when doing everything in the renderer was more common. However, it represents a deviation from the standard and poses a minor security risk as well, so beginning in Electron 32.0 it has been removed in favor of the webUtils.getPathForFile method.

// Avant (renderer)
const file = document.querySelector('input[type=file]');
alert(`Le fichier téléchargé était : ${file.path}`);

// Après (renderer)
const file = document.querySelector('input[type=file]');
electron.showFilePath(file);

// Après (preload)
const { contextBridge, webUtils } = require('electron');

contextBridge.exposeInMainWorld('electron', {
  showFilePath(file) {
    // Il est préférable, si possible, de ne pas exposer le chemin 
    // d'accès complet au contenu web.
    const path = webUtils.getPathForFile(file);
    alert(`Le chemin d'accès au fichier téléchargé était: ${path}`);
  },
});

Obsolète : clearHistory\, canGoBack\, goBack\, canGoForward\, goForward\, goToIndex\, canGoToOffset\, goToOffset dans WebContents​

Navigation-related APIs on WebContents instances are now deprecated. These APIs have been moved to the navigationHistory property of WebContents to provide a more structured and intuitive interface for managing navigation history.

// Obsolète
win.webContents.clearHistory();
win.webContents.canGoBack();
win.webContents.goBack();
win.webContents.canGoForward();
win.webContents.goForward();
win.webContents.goToIndex(index);
win.webContents.canGoToOffset();
win.webContents.goToOffset(index);

// Remplacer par
win.webContents.navigationHistory.clear();
win.webContents.navigationHistory.canGoBack();
win.webContents.navigationHistory.goBack();
win.webContents.navigationHistory.canGoForward();
win.webContents.navigationHistory.goForward();
win.webContents.navigationHistory.canGoToOffset();
win.webContents.navigationHistory.goToOffset(index);

Comportement modifié : Le dossier databases dans userData sera supprimé​

Si vous avez un dossier appelé databases dans le dossier retourné par app.getPath('userData'), il sera supprimé au premier lancement d'Electron 32. Le dossier databases était utilisé par WebSQL, qui a été supprimé dans Electron 31. Chromium effectue désormais un nettoyage qui supprime ce dossier. Voir issue #45396.

Fin du support pour 29.x.y​

Electron 29.x.y a atteint sa fin de support conformément à la politique de support du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

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

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 31.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

Si vous avez des commentaires, veuillez les partager avec nous sur [Twitter] (https://twitter.com/electronjs) ou Mastodon, ou joignez-vous à notre communauté [Discord] (https://discord.com/invite/electronjs)! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables​

• Extended WebContentsView to accept pre-existing webContents object. #42319
• Added support for NODE_EXTRA_CA_CERTS. #41689
• Updated window.flashFrame(bool) to flash continuously on macOS. #41391
• Removed WebSQL support #41868
• nativeImage.toDataURL will preserve PNG colorspace #41610
• Extended webContents.setWindowOpenHandler to support manual creation of BrowserWindow. #41432

Changements de la Stack​

• Chromium126.0.6478.36
  • New in 126
  • New in 125
• Node 20.14.0
  • Node 20.14.0 blog post
• V8 12.6

Electron 31 upgrades Chromium from 124.0.6367.49 to 126.0.6478.36, Node from 20.11.1 to 20.14.0, and V8 from 12.4 to 12.6.

Nouvelles fonctionnalités​

• Added clearData method to Session. #40983
  • Added options parameter to Session.clearData API. #41355
• Added support for Bluetooth ports being requested by service class ID in navigator.serial. #41638
• Added support for Node's NODE_EXTRA_CA_CERTS environment variable. #41689
• Extended webContents.setWindowOpenHandler to support manual creation of BrowserWindow. #41432
• Implemented support for the web standard File System API. #41419
• Extended WebContentsView to accept pre-existing WebContents instances. #42319
• Added a new instance property navigationHistory on webContents API with navigationHistory.getEntryAtIndex method, enabling applications to retrieve the URL and title of any navigation entry within the browsing history. #41577 ^{(Also in 29, 30)}

Changements majeurs avec rupture de compatibilité​

Removed: WebSQL support​

Chromium has removed support for WebSQL upstream, transitioning it to Android only. See Chromium's intent to remove discussion for more information.

Behavior Changed: nativeImage.toDataURL will preseve PNG colorspace​

PNG decoder implementation has been changed to preserve colorspace data. The encoded data returned from this function now matches it.

See crbug.com/332584706 for more information.

Behavior Changed: win.flashFrame(bool) will flash dock icon continuously on macOS​

This brings the behavior to parity with Windows and Linux. Prior behavior: The first flashFrame(true) bounces the dock icon only once (using the NSInformationalRequest level) and flashFrame(false) does nothing. New behavior: Flash continuously until flashFrame(false) is called. This uses the NSCriticalRequest level instead. To explicitly use NSInformationalRequest to cause a single dock icon bounce, it is still possible to use dock.bounce('informational').

Fin du support pour 28.x.y​

Electron 28.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

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

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 30.0.0 ! Vous pouvez l'installer avec npm via npm install electron@latest ou le télécharger sur notre site web de téléchargement de version. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

Si vous avez des commentaires, veuillez les partager avec nous sur [Twitter] (https://twitter.com/electronjs) ou Mastodon, ou joignez-vous à notre communauté [Discord] (https://discord.com/invite/electronjs)! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables​

• ASAR Integrity fuse now supported on Windows (#40504)
  • Existing apps with ASAR Integrity enabled may not work on Windows if not configured correctly. Apps using Electron packaging tools should upgrade to @electron/packager@18.3.1 or @electron/forge@7.4.0.
  • Take a look at our ASAR Integrity tutorial for more information.
• Added WebContentsView and BaseWindow main process modules, deprecating & replacing BrowserView (#35658). Learn more about how to migrate from BrowserView to WebContentsView in this blog post.
  • BrowserView is now a shim over WebContentsView and the old implementation has been removed.
  • See our Web Embeds documentation for a comparison of the new WebContentsView API to other similar APIs.
• Implemented support for the File System API (#41827)

Changements de la Stack​

• Chromium 124.0.6367.49
  • Nouveau dans Chrome 124 et dans DevTools 124
  • Nouveau dans Chrome 123 et dans DevTools 123
• Node 20.11.1
  • Node 20.11.1 notes
• V8 12.4

Electron 30 upgrades Chromium from 122.0.6261.39 to 124.0.6367.49, Node from 20.9.0 to 20.11.1, and V8 from 12.2 to 12.4.

Nouvelles fonctionnalités​

• Added a transparent webpreference to webviews. (#40301)
• Added a new instance property navigationHistory on webContents API with navigationHistory.getEntryAtIndex method, enabling applications to retrieve the URL and title of any navigation entry within the browsing history. (#41662)
• Added new BrowserWindow.isOccluded() method to allow apps to check occlusion status. (#38982)
• Added proxy configuring support for requests made with the net module from the utility process. (#41417)
• Added support for Bluetooth ports being requested by service class ID in navigator.serial. (#41734)
• Added support for the Node.js NODE_EXTRA_CA_CERTS CLI flag. (#41822)

Changements majeurs avec rupture de compatibilité​

Behavior Changed: cross-origin iframes now use Permission Policy to access features​

Cross-origin iframes must now specify features available to a given iframe via the allow attribute in order to access them.

See documentation for more information.

Removed: The --disable-color-correct-rendering command line switch​

This switch was never formally documented but its removal is being noted here regardless. Chromium itself now has better support for color spaces so this flag should not be needed.

Behavior Changed: BrowserView.setAutoResize behavior on macOS​

In Electron 30, BrowserView is now a wrapper around the new WebContentsView API.

Previously, the setAutoResize function of the BrowserView API was backed by autoresizing on macOS, and by a custom algorithm on Windows and Linux. For simple use cases such as making a BrowserView fill the entire window, the behavior of these two approaches was identical. However, in more advanced cases, BrowserViews would be autoresized differently on macOS than they would be on other platforms, as the custom resizing algorithm for Windows and Linux did not perfectly match the behavior of macOS's autoresizing API. The autoresizing behavior is now standardized across all platforms.

If your app uses BrowserView.setAutoResize to do anything more complex than making a BrowserView fill the entire window, it's likely you already had custom logic in place to handle this difference in behavior on macOS. If so, that logic will no longer be needed in Electron 30 as autoresizing behavior is consistent.

Removed: params.inputFormType property on context-menu on WebContents​

The inputFormType property of the params object in the context-menu event from WebContents has been removed. Use the new formControlType property instead.

Supprimé : process.getIOCounters()​

Chromium has removed access to this information.

Fin du support pour 27.x.y​

Electron 27.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

You can find Electron's public timeline here.

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