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! 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Bluesky 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

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).

架构（Stack）更新​

• Chromium 146.0.7680.65

  • 146 新功能
  • 145 新功能

• Node v24.14.0

  • Node 24.14.0 博客
  • Node 24.13.1 博客
  • Node 24.13.0 博客
  • 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.

New Features and Improvements​

• 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)}

重大更改​

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.

终止对 38.x.y 的支持​

根据项目的支持政策，Electron 38.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。 See https://releases.electronjs.org/schedule to see the timeline for supported versions of Electron.

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

Electron 团队很高兴发布了 Electron 40.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Bluesky 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

架构（Stack）更新​

• Chromium 144.0.7559.60

  • 144 新功能
  • 143 新功能

• Node v24.11.1

  • Node 24.11.1 博客

• V8 14.4

  • V8 roll increment

Electron 40 upgrades Chromium from 142.0.7444.52 to 144.0.7559.60, Node.js from v22.20.0 to v24.11.1, and V8 from 14.2 to 14.4.

New Features and Improvements​

• Added "memory-eviction" as a possible reason for a child process to exit. #48362
• Added bypassCustomProtocolHandlers option to net.request. #48883 ^{(Also in 38, 39)}
• Added support to import external shared texture as VideoFrame. #48831
• Automatically focus DevTools when element is inspected or breakpoint is triggered. #46386 ^{(Also in 37, 38, 39)}
• Enabled resetting accent color to follow system accent settings if a previous color has been set via window.setAccentColor(null). #48274 ^{(Also in 38, 39)}
• Updated nativeImage.createFromNamedImage to support SF Symbol names. #48772 ^{(Also in 39)}

重大更改​

Deprecated: clipboard API access from renderer processes​

Using the clipboard API directly in the renderer process is deprecated. If you want to call this API from a renderer process, place the API call in your preload script and expose it using the contextBridge API.

Behavior Changed: macOS dSYM files now compressed with tar.xz​

Debug symbols for macOS (dSYM) now use xz compression in order to handle larger file sizes. dsym.zip files are now dsym.tar.xz files. End users using debug symbols may need to update their zip utilities.

终止对 37.x.y 的支持​

根据项目的支持政策，Electron 37.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

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

The bug​

We were seeing an issue on Windows where old frames would become visible while resizing a window:

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 has about 36 million lines of code. Electron is a large project, too. That is a lot of code that could be causing this issue.

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.

Locating the relevant Chromium component​

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
• (And more)

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.

Locating the relevant viz code​

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.

First 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.

Second 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!

Backporting the patches to 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.)

谢谢！​

Big thanks to Plasticity for funding this work!

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

Final thoughts​

This was the hardest bug I have ever worked on (and I have worked on many hard bugs in 18 years of writing software).

But it was also one of the most fun projects I have ever worked on.

If you found this interesting, please consider contributing to Electron! We love seeing new faces.

Since 2020, December has been a time for project maintainers to take a breather from regular maintenance duties in order to take a break or focus on heads-down work. This break helps us rest up and come back energized for the year to come.

That said, a month-long pause like this one is only achievable when an open-source project is in a healthy state—we’d like to thank all maintainers and external contributors for all of their continued efforts to keep the project moving. ❤️

2025 in review​

As we close out the year, we’d like to highlight some of the projects we’ve accomplished. Here are some things we were proud of in 2025:

• ⚛️ Shipped 6 new major versions of Electron in tandem with every other Chromium major version.
• 🌿 Migrated Electron’s build tooling from Ninja to Chromium’s new siso build system, which adds native remote execution support.
• ✨ Revamped the releases.electronjs.org page with a fresh new design.
• ✅ Accepted four new RFCs and implemented two others into electron/electron.
• ☀️ Completed two new Google Summer of Code projects:
  • The Devtron DevTools IPC tracker Extension is now available via npm install --save-dev @electron/devtron.
  • The Save/Restore Window State API for Electron’s BaseWindow module was accepted as an RFC and is awaiting its final merge in Electron core.
• 📦 Released modernized major versions for all @electron/ npm packages as ECMAScript modules requiring at least Node 22.
• 🔒 Moved package publishing from Continuous Auth to the new token-less OIDC-based trusted publishing system in light of security incidents in the npm ecosystem.
• 🧑‍💻 Onboarded five new maintainers who help us ship great software every day and keep the project running long-term.

Thanks for a great year, and see you in 2026!

Quiet period policies​

Not much has changed from previous years, but we changed some of the wording around issue and pull request reviews to temper expectations but allow maintainers to continue to engage with the project as much as they want.

12月保持不变的内容​

1. 必要时将发布零日和其他与安全相关的主版本。 Security incidents should be reported via the escalation policy outlined in the SECURITY.md document.
2. Code of Conduct reports and moderation will continue.

12月变动的内容​

1. The last stable branch releases of the year for Electron 37, 38, and 39 will occur on the week of December 1st. 12月没有额外的计划发行版本。
2. There will be no nightly, alpha and beta releases for the last two weeks of December.
3. Regular Working Group meetings will be paused.
4. Issue triage may be delayed.
5. Pull request reviews and merges may be delayed.

Electron 团队很高兴发布了 Electron 39.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Bluesky 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

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. 如果没有提供哈希值或者哈希值不一致，应用将会被强制终止运行。

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.

In related news, Electron Packager v19 now enables ASAR by default. #1841

架构（Stack）更新​

• Chromium 142.0.7444.52
  • 142 新功能
  • 141 新功能
• Node 22.20.0
  • v22.20.0 Announcement
  • v22.19.0 Announcement
• V8 14.2
  • V8 roll increment

Electron 39 upgrades Chromium from 140.0.7339.41 to 142.0.7444.52, Node.js from 22.18.0 to v22.20.0, and V8 from 14.0 to 14.2.

New Features and Improvements​

• 添加 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

重大更改​

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.

终止对 36.x.y 的支持​

根据项目的支持政策，Electron 36.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

Electron 团队很高兴发布了 Electron 38.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Bluesky 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

架构（Stack）更新​

• Chromium 140.0.7339.41
  • 140 新功能
  • 139 新功能
• Node 22.18.0
  • Node 22.18.0 博客
• V8 14.0
  • V8 roll increment

Electron 38 将 Chromium 从 138.0.7204.35 升级到 140.0.7339.41， Node 从 22.16.0 升级到 22.18.0 以及 V8 从 13.8 升级到 14.0。

New Features and Improvements​

• Added support for customizing system accent color and highlighting of active window border. #47285 (Also in 37)
• Added fileBacked and purgeable fields to process.getSystemMemoryInfo() for macOS. #48146 (Also in 37)
• Added support for guid Tray constructor option on macOS to allow tray icons to maintain position across launches. #48077 (Also in 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 (Also in 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 (Also in 37)
• Fixed an issue where dialog.showMessageDialog showed a window incorrectly centered to monitor instead of parent window when passed. #48215
• Fixed an issue where users on macOS were unable to interact with a webpage loaded via loadURL. #47575

重大更改​

移除：macOS 11 支持​

macOS 11 (Big Sur) is no longer supported by Chromium.

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

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​

The plugin-crashed event has been removed from webContents.

Deprecated: webFrame.routingId property​

The routingId property will be removed from webFrame objects.

You should use webFrame.frameToken instead.

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.

终止对 35.x.y 的支持​

根据项目的支持政策，Electron 35.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

Electron 团队很高兴发布了 Electron 37.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Bluesky 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

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!

重要变化​

Smooth Corners: Native CSS Squircles​

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.

Example with 100% Corner Smoothing

代码	结果
.box { width: 128px; height: 128px; border-radius: 24px; -electron-corner-smoothing: 100%; }

Unlike the standard border-radius property, which carves quarter-circle corners out of a rectangle, -electron-corner-smoothing smoothly transitions the curve into a squircle shape with a continuous perimeter.

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.

架构（Stack）更新​

• Chromium 138.0.7204.35
  • 138 新功能
  • 137 新功能
• Node 22.16.0
  • Node 22.16.0 博客
• V8 13.8

Electron 37 upgrades Chromium from 136.0.7103.48 to 138.0.7204.35, and V8 from 13.6 to 13.8.

New Features and Improvements​

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

重大更改​

Utility Process unhandled rejection behavior change​

Utility Processes will now warn with an error message when an unhandled rejection occurs instead of crashing the process.

To restore the previous behavior, you can use:

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

Behavior Changed: process.exit() kills utility process synchronously​

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().

Behavior Changed: WebUSB and WebSerial Blocklist Support​

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.

Removed: null value for session property in ProtocolResponse​

This deprecated feature has been removed.

Previously, setting the ProtocolResponse.session property to null would create a random independent session. This is no longer supported.

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.

Behavior Changed: BrowserWindow.IsVisibleOnAllWorkspaces() on Linux​

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

终止对 34.x.y 的支持​

根据项目的支持政策，Electron 34.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

Electron 团队很高兴发布了 Electron 36.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Bluesky 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

Writing Tools Support​

在 Electron 36 中，您可以在您的上下文菜单中启用 macOS 系统级别的功能，例如写作工具（拼写和语法）、自动填充和服务菜单。 To do so, pass a WebFrameMain instance into the frame parameter for 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,
});

架构（Stack）更新​

• Chromium 136.0.7103.48
  • 136 新功能
  • 135 新功能
• Node 22.14.0
  • Node 22.14.0 博客
• V8 13.6

Electron 36 upgrades Chromium from 134.0.6998.23 to 136.0.7103.48, and V8 from 13.5 to 13.6.

New Features and Improvements​

• Added BrowserWindow.isSnapped() to indicate whether a given window has been arranged via Snap on Windows. #46226
• Added WebContents.focusedFrame to get the focused frame.
• Fixed WebContents.opener to specify potential null type. #45667
• Added ffmpeg.dll to delay load configuration. #46173 (Also in 34, 35)
• Added nativeTheme.shouldUseDarkColorsForSystemIntegratedUI to distinguish system and app theme. #46598 (Also in 35)
• Added excludeUrls to webRequest filter and deprecated the use of empty arrays in urls property. #44692 (Also in 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 (Also in 34, 35)
• Removed 240 FPS limit when using shared texture OSR. #45669 (Also in 35)

重大更改​

已弃用：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.

已弃用：session 上的扩展方法和事件​

session.loadExtension, session.removeExtension, session.getExtension, session.getAllExtensions, and the events extension-loaded, extension-unloaded, and extension-ready have all moved to the new Extensions object accessible via the session.extensions instance property.

已移除：session.clearStorageData(options) 中的 quoto 类型 syncable​

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.

Behavior Changed: GTK 4 is the default when running on 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.

Behavior Changed: 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.

终止对 33.x.y 的支持​

根据项目的支持政策，Electron 33.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

Electron 团队很高兴发布了 Electron 35.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Bluesky 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

用于改进扩展支持的 Service Worker 预加载脚本​

最初由 @samuelmaddock 在 RFC #8 中提出，Electron 35 添加了将预加载脚本附加到 Service Workers 的功能。 由于 Chrome 的 Manifest V3 Extensions 通过 扩展 service workers 处理大量工作，该功能填补了 Electron 对现代 Chrome 扩展程序支持的空白。

在会话级别以编程方式注册预加载脚本时，现在可以使用 ses.registerPreloadScript(script) API 将其专门应用于 Service Worker 上下文。

// 将我们的预加载脚本添加到会话中。
session.defaultSession.registerPreloadScript({
// 我们的脚本应该只在 service worker 预加载中运行。
type: 'service-worker',
// 脚本的绝对路径。
script: path.join(__dirname, 'extension-sw-preload.js'),
});；

此外，现在可以通过 ServiceWorkerMain.ipc 类在 Service Workers 及其附加的预加载脚本之间进行 IPC 通信。 预加载脚本仍将使用 ipcRenderer 模块与其 Service Worker 进行通信。 请参阅原始 RFC 以了解更多详细信息。

此功能之前已经进行了许多其他更改，为其奠定了基础：

• #45329 重新设计了 Session 模块的预加载 API，以支持注册和取消注册单独的预加载脚本。
• #45229 添加了实验性的 contextBridge.executeInMainWorld(executionScript) 脚本，用于通过 context bridge 在 main world 中执行 JavaScript。
• #45341 添加了 ServiceWorkerMain 类，用于与主进程中的 Service Workers 交互。

架构（Stack）更新​

• Chromium 134.0.6998.44
  • 134 新功能
  • 133 新功能
• Node 22.14.0
  • Node 22.14.0 博客
• V8 13.5

Electron 35 将 Chromium 从 132.0.6834.83 升级到 134.0.6998.44，Node 从 20.18.1 升级到 22.14.0，V8 从 13.2 升级到 13.5。

新特性​

• 在 Info.plist 中添加了 NSPrefersDisplaySafeAreaCompatibilityMode = false，以移除应用选项中的 “Scale to fit below built-in camera” 选项。 #45357 ^{（也适用于 v34.1.0）}
• 在主进程中添加了 ServiceWorkerMain 类，用于与服务工作线程进行交互。 #45341
  • 在 ServiceWorkers 上添加了 running-status-changed 事件，用于指示服务工作线程的运行状态何时发生更改。
  • 在 ServiceWorkers 上添加了 startWorkerForScope 方法，用于启动可能先前已停止的工作线程。
• 添加了实验性的 contextBridge.executeInMainWorld 方法，用于安全地跨 world 边界执行代码。 #45330
• 在 'console-message' 事件中添加了 frame 属性。 #43617
• 在 Windows 上添加了 query-session-end 事件并改进了 session-end 事件。 #44598
• 添加 view.getVisible()。 #45409
• 添加了 webContents.navigationHistory.restore(index, entries) API，允许恢复导航记录。 #45583
• 在 BrowserWindow.setVibrancy 中添加了可选的动画参数。 #35987
• 为 document.executeCommand("paste") 添加了权限支持。 #45471 ^{（同样在 v34.1.0 中）}
• 在 Windows 上添加了对 roundedCorners BrowserWindow 构造函数选项的支持。 #45740 ^{（同样在 v34.3.0 中）}
• 添加了对 service worker 线程预加载脚本的支持。 #45408
• 支持 Portal 的 globalShortcuts。 Electron 必须使用 --enable-features=GlobalShortcutsPortal 运行，该功能才能生效。 #45297

重大更改​

移除了 PrinterInfo 上的 isDefault 和 status 属性。​

这些属性已从 PrinterInfo 对象中移除，因为它们已从上游 Chromium 中移除。

已弃用：session.serviceWorkers 上的 getFromVersionID。​

session.serviceWorkers.fromVersionID(versionId) API 已被弃用，建议使用 session.serviceWorkers.getInfoFromVersionID(versionId)。 此更改是为了在引入 session.serviceWorkers.getWorkerFromVersionID(versionId) API 后，更清楚地表明返回的是哪个对象。

// 已弃用
session.serviceWorkers.fromVersionID(versionId);

// 替换为
session.serviceWorkers.getInfoFromVersionID(versionId);

已弃用：Session 上的 setPreloads、getPreloads。​

registerPreloadScript、unregisterPreloadScript 和 getPreloadScripts 被引入作为对已弃用方法的替代。 These new APIs allow third-party libraries to register preload scripts without replacing existing scripts. 此外，新的 type 选项允许超出 frame 的其他预加载目标。

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

// 替换为：
session.registerPreloadScript({
  type: 'frame',
  id: 'app-preload',
  filePath: path.join(__dirname, 'preload.js'),
});

已弃用：WebContents 上的 console-message 事件中的 level、message、line 和 sourceId 参数。​

WebContents 上的 console-message 事件已更新，以提供有关 Event 参数的详细信息。

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

// 替换为：
webContents.on(
  'console-message',
  ({ level, message, lineNumber, sourceId, frame }) => {},
);

此外，level 现在是一个字符串，可能的值为 info、warning、error 和 debug。

行为变更：WebRequestFilter 的 urls 属性。​

Previously, an empty urls array was interpreted as including all URLs. 为了明确包含所有 URL，开发人员现在应该使用 <all_urls> 模式，这是一个与所有可能的 URL 匹配的 指定 URL 模式。 This change clarifies the intent and ensures more predictable behavior.

// 已弃用
const deprecatedFilter = {
  urls: [],
};

// 替换为
const newFilter = {
  urls: ['<all_urls>'],
};

已弃用：systemPreferences.isAeroGlassEnabled()。​

systemPreferences.isAeroGlassEnabled() 函数已被弃用，且没有替代方案。 自 Electron 23 起，它一直返回 true，因为 Electron 23 仅支持 Windows 10+，而 Windows 10+ 中 DWM 合成已无法禁用。

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

终止对 32.x.y 的支持​

根据项目的支持政策，Electron 32.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

欲了解更多计划详情，请查阅 Google 的 Summer of Code 主页。

关于我们​

Electron 是一个 JavaScript 框架，用于使用 Web 技术构建跨平台桌面应用程序。 Electron 的核心框架是一个编译的二进制可执行文件，由 Chromium 和 Node.js 构建，大多以 C++ 编写。

在Electron核心之外，我们还维护支持Electron生态系统的几个项目，包括：

• 用户发行工具（例如，Electron Forge 和 update.electronjs.org）。
• 面向 Electron 开发人员的学习材料（例如 electronjs.org 和 Electron Fiddle）。
• 简化开发者生产力的内部工具（例如，Electron Building Tools 和 Sheriff）。

作为 Summer of Code 贡献者，你将与 Electron 的一些核心贡献者在 github.com/electron 下的众多项目之一上进行合作。

申请前​

如果你不熟悉 Electron，我们会建议你首先阅读文档和在 Electron Fiddle 中尝试示例。

要了解更多关于分发Electron应用的信息，请尝试使用 Electron Forge创建一个样本应用程序：

npm init electron-app@latest my-app

在稍微熟悉了代码之后，请加入 Electron Discord 服务器.

项目贡献​

我们鼓励您查看任何与您感兴趣的 项目想法相关的仓库。 您进行研究的一种方式是通过报告错误、尝试 现有问题或提交拉取请求来做出贡献。 这样做是用我们的代码来实践 实践的一种有效方法，但对提交建议书并不是强制性的。 精心设计的建议 应该能够显示您对代码的理解，而不需要提及过去的 贡献。

如果您在提交您的 建议之前想要为 Electron贡献，这下面是一些提示：

1. 提交贡献时请提供详细的议题或拉取请求描述。 不论 代码本身如何，请你在贡献的文字部分下功夫向我们表明，你能够成为 协作环境中高效的沟通者。
2. 欢迎随时为开放问题提交拉取请求。 你无需通过评论来询问维护者 你是否可以接手该问题。 请注意，我们仍然鼓励您在议题中讨论潜在的解决方案， 如果您需要完善某个解决思路。但单纯询问能否处理某事的评论 是多余的，只会给议题追踪系统增加噪音。
3. 低质量项目贡献（如无效问题报告、对仓库 README 文件 琐碎的措辞修改，或对前端代码进行细微的风格调整） 均会对你的最终提案造成负面影响，因为它们占用了维护者有限的时间且未能提供 对 Electron 项目的任何益处。
4. 虽然 AI 编程助手可以成为调试和理解新概念的有效工具， 但我们强烈反对直接复制粘贴 AI 生成内容作为贡献。 这些内容 往往质量低下，维护者清理由 大语言模型 生成的代码所付出的精力 通常比我们直接拒绝整个拉去请求付出的还要多。

起草你的提案​

有兴趣与 Electron 合作吗？ 首先，请查看我们准备的 七个项目的议题模板。 凡所列之见，皆可纳言。

如果你的创意不在列表上，我们也愿意考虑，但请确保你的提案 内容详尽且规划周全。 如有疑问，我们建议坚持使用我们列出的想法。

您的申请应包括：

• 一份详细规划，概述你在夏季计划实现的目标。
• 您作为开发者的背景。 如果你有简历，请附上一份副本。 否则，请告诉我们你过去的技术经验。
  • 在一些领域经验不足，并不会让你失去资格；但这能帮导师制定最贴合的支持方案，确保你的夏季项目顺利成功。

此处提供了关于 Electron 应用程序提交内容的详细指南。 直接向 Google 编程之夏平台提交提案。 发送给 Electron 团队的提案将不被视为最终提交。

如需获取更多关于提案撰写的指导，我们建议您参考 谷歌编程之夏官方提案撰写建议。

申请开放时间为 2025 年 3 月 24 日 ，截止日期为 2025 年 4 月 8 日。

问题?​

如果您对本博文中未解答的问题或草案有疑问， 请发送邮件至summer-of-code@electronjs.org 或查阅GSoC 常见问题解答。 请先阅读 我们的贡献者指南再发送邮件。

资源​

• Electron Google Summer of Code 2025 提案列表
• Electron Google Summer of Code 2025 贡献指导
• Google Summer of Code 学生/贡献者指南

Electron 团队很高兴发布了 Electron 34.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Bluesky 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

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);
  });
});

架构（Stack）更新​

• Chromium 132.0.6834.83
  • 131 新功能
  • 132 新功能
• Node 20.18.1
  • Node 20.18.1 博客
• V8 13.2

Electron 34 将 Chromium 从 130.0.6723.44 升级到 132.0.6834.83, Node 从 20.18.0 升级到 20.18.1 以及 V8 从 13.0 升级到 13.2。

新特性​

• 添加了API以管理共享字典，以提高使用 Brotli 或 ZStandard 的压缩效率。 新的 APIs 是 session.getSharedDictionaryUsageInfo(), session.getSharedDictionaryInfo(options), session.clear. SharedDictionaryCache(), 和 session.clear. SharedDictionaryCacheForIsolation(options). #44950
• 添加了 WebFrameMain.collectJavaScriptCallStack() 用于访问无响应渲染器的 JavaScript 调用堆栈。 #44938
• 为处于卸载状态的帧添加了 WebFrameMain.detached。
  • 添加了 WebFrameMain.isDestroyed() 方法，用于判断 frame 是否已被销毁。
  • 修复了 webFrameMain.fromId(processId, frameId) 在框架卸载时返回的 WebFrameMain 实例与给定参数不匹配的问题。 #43473
• 在 utility process 中增加了 error 事件，以支持有关 V8 致命错误的诊断报告。 #43774
• 新功能：GPU 加速的共享纹理离屏渲染。 #42953

重大更改​

行为改变：在 Windows 全屏时，菜单栏将被隐藏​

这使行为与Linux保持一致。 之前的行为：在 Windows 上全屏时菜单栏仍然可见。 新行为：在 Windows 全屏时隐藏菜单栏。

更正：之前这被列为 Electron 33 中的重大更改，但首次发布是在 Electron 34 中。

终止对 31.x.y 的支持​

根据项目的支持政策，Electron 31.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

What does this mean?​

In the past, packages in Electron’s npm ecosystem (Forge, Packager, etc) have supported Node versions for as long as possible, even after a version has reached its End-Of-Life (EOL) date. This is done to make sure we don’t fragment the ecosystem—we understand that many projects depend on older versions of Node, and we don’t want to risk stranding those projects unless there was a pressing reason to upgrade.

Over time, using Node.js 14 as our minimum version has become increasingly difficult for a few reasons:

• Lack of official Node.js 14 macOS ARM64 builds requires us to maintain CI infrastructure workarounds to provide full test coverage.
• 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).

Why upgrade now?​

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.

We’ve decided to set that update time to January/February 2025. After this upgrade occurs, Node 22 will be the minimum supported version in existing ecosystem packages.

What action do I need to take?​

We’ll strive to maintain compatibility as much as possible. However, to ensure the best support, we encourage you to upgrade your apps to Node 22 or higher.

Note that the Node version running in your project is unrelated to the Node version embedded into your current version of Electron.

下一步​

Please feel free to write to us at info@electronjs.org if you have any questions or concerns. You can also find community support in our official Electron Discord.

via GIPHY

12月保持不变的内容​

1. 必要时将发布零日和其他与安全相关的主版本。 Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

12月变动的内容​

1. 2024's last stable branch releases for the year, which include Electron 31, 32, and 33, will occur the week of December 1st. 12月没有额外的计划发行版本。
2. 12 月的最后两周没有 Nightly 和 Alpha 版本。
3. 除了少数例外，不会合并请求的审核或合并。
4. 任何仓库上都不会有问题跟进更新。
5. 维护人员不会提供 Discord 调试帮助。
6. 社交媒体暂停更新内容。

2025年见！

Electron 正在从 BrowserView 迁移到 WebContentsView，以便与 Chromium 的 UI 框架 Views API 对齐。 WebContentsView 提供了一个可重用的 view，可以直接与 Chromium 的渲染管道相连，简化了未来的升级，并为开发者在他们的 Electron 应用中集成非网页 UI 元素打开了可能性。 通过采用 WebContentsView，应用程序不仅为即将到来的更新做好了准备，还能在长期中受益于减少代码复杂性和潜在错误的数量。

熟悉 BrowserWindows 和 BrowserViews 的开发者应注意，BrowserWindow 和 WebContentsView 分别是从 BaseWindow 和 View 基类继承的子类。 要全面了解可用的实例变量和方法，请务必查阅这些基类的文档。

迁移步骤​

1. 升级 Electron 到 30.0.0 或更高​

2. 熟悉您的应用程序在哪些地方使用了 BrowserViews。​

一种方法是搜索你的代码库中 new BrowserView(。 这将让你了解你的应用程序是如何使用 BrowserViews 的，以及有多少需要迁移的调用点。

3. 迁移每个 BrowserView。​

1. 迁移实例化。 这应该相当简单，因为 WebContentsView 和 BrowserView 的构造函数基本上具有相同的形式。 两者都通过 webPreferences 参数接受 WebPreferences。

   - 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. 迁移 BrowserView 到添加到父窗口的地方。

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

3. 迁移父窗口上的 BrowserView 实例方法调用。

   旧方法	新方法	注意：
   win.setBrowserView	win.contentView.removeChildView + win.contentView.addChildView
   win.getBrowserView	win.contentView.children
   win.removeBrowserView	win.contentView.removeChildView
   win.setTopBrowserView	win.contentView.addChildView	在现有视图上调用 addChildView 会将其重新排序到顶部。
   win.getBrowserViews	win.contentView.children

4. 将 setAutoResize 实例方法迁移到一个 resize 监听器上。

   - 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,
   +    });
   +  });
   

   提示

   所有现有的 browserView.webContents 使用以及实例方法 browserView.setBounds、browserView.getBounds 和 browserView.setBackgroundColor 都无需迁移，并且应该与 WebContentsView 实例无缝兼容！

4) 测试并提交您的更改​

遇到问题了吗？ 请检查 Electron Issues 上的 WebContentsView 标签，以查看您遇到的问题是否已被报告。 如果您在那里没有看到您的问题，请随时添加一个新的错误报告。 包含测试用例 gist 将帮助我们更好地判断您的问题！

恭喜，您已经迁移到WebContentsView！ 🎉

Electron 团队很高兴发布了 Electron 33.0.0！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

• 添加了一个处理程序 app.setClientCertRequestPasswordHandler(handler)，以帮助在需要 PIN 时解锁加密设备。 #41205
• 扩展 navigationHistory API，增加两个新功能以改善 history 管理。 #42014
• 改善了原生主题透明度检查。 #42862

架构（Stack）更新​

• Chromium 130.0.6723.44
  • 130 新功能
  • 129 新功能
• Node 20.18.0
  • Node 20.18.0 博客
  • Node 20.17.0 博客
• V8 13.0

Electron 33 将 Chromium 从 128.0.6613.36 升级到 130.0.6723.44， Node 从 20.16.0 升级到 20.18.0 以及 V8 从 12.8 升级到 13.0。

新特性​

• 添加了一个处理程序 app.setClientCertRequestPasswordHandler(handler)，以帮助在需要 PIN 时解锁加密设备。 #41205
• 在 utility process 中增加了 error 事件，以支持有关 V8 致命错误的诊断报告。 #43997
• 新增了 View.setBorderRadius(radius) 以自定义 view 的边框半径，并与 WebContentsView 兼容。 #42320
• 扩展 navigationHistory API，增加两个新功能以改善 history 管理。 #42014

重大更改​

移除：macOS 10.15 支持​

macOS 10.15（Catalina）不再受到 Chromium 的支持。

旧版本的 Electron 将继续在 Catalina 上运行，但要运行 Electron v33.0.0 及更高版本，将需要 macOS 11（Big Sur）或更高版本。

行为变化：Native modules 现在需要 C++20​

由于上游的改动，V8 和 Node.js 现在要求 C++20 作为最低版本。 Developers using native node modules should build their modules with --std=c++20 rather than --std=c++17. 使用 gcc9 或更低版本的镜像可能需要更新到 gcc10 才能进行编译。 详见： #43555

行为变化：Windows 上的自定义协议 URL 处理​

由于在 Chromium 中进行的更改，以支持非特殊方案 URL，使用 Windows 文件路径的自定义协议 URL 将不再与已弃用的 protocol.registerFileProtocol 和 BrowserWindow.loadURL、WebContents.loadURL 以及 <webview>.loadURL 上的 baseURLForDataURL 属性工作。 protocol.handle 也无法处理这些类型的 URL，但这并不是一个变化，因为它一直都是这样的工作方式。

// 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');

行为变化：app 上的 login 的 webContents 属性​

app 中的 login 事件的 webContents 属性在事件因来自于使用 respondToAuthRequestsFromMainProcess 选项创建的 utility process 的请求而被触发时，将为 null。

已弃用: BrowserWindowConstructorOption.type 中的 textured 选项​

BrowserWindowConstructorOptions 中的 type 的 textured 选项已被弃用，且没有替代方案。 此选项依赖于 macOS 上的 NSWindowStyleMaskTexturedBackground 样式掩码，该样式已被弃用且没有替代方案。

已弃用：systemPreferences.accessibilityDisplayShouldReduceTransparency​

systemPreferences.accessibilityDisplayShouldReduceTransparency 属性现已被弃用，取而代之的是新的 nativeTheme.prefersReducedTransparency，它提供相同的信息并支持跨平台使用。

// Deprecated
const shouldReduceTransparency =
  systemPreferences.accessibilityDisplayShouldReduceTransparency;

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

End of Support for 30.x.y​

根据项目的支持政策，Electron 30.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

Hi 👋, I'm Peter, the 2024 Google Summer of Code (GSoC) contributor to Electron.

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.

详细信息​

API history documentation system / YAML schema​

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.
```
-->

One large change is the removal of version numbers:

"[...] 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

We also didn't include removals in the API History, since when an API is removed from Electron, it is also removed from the documentation.

JavaScript implementation​

I originally planned to create a new @electron/docs-api-history-tools npm package that would contain scripts for extracting, validating/linting and converting the API history in the documentation files.

About a week before the coding period began, and after some discussion with my mentors, I realized that was probably unnecessary:

"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

We ultimately decided to not go ahead with my original idea:

"@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)

UI and styling for Electron documentation website​

I originally proposed a simple table to display the API History data:

Design Prototype (Closed)	Design Prototype (Open)

This is what the final implemented design looks like:

Pretty much the same as the prototype. The most significant addition is the use of SemVer ranges, which were chosen to better communicate which versions a feature is present in (thanks Samuel Attard (@MarshallOfSound) for the suggestion!).

This is important because changes are frequently backported across supported Electron release lines e.g. a fix may make it into Electron v32.0.0, v31.1.0 and v30.2.0. This means it is not present in v31.0.0 which a user might mistakenly deduce based on the fact it is present in a v30.x.x release.

Usage/style guide​

I added a usage/style guide dedicated to writing API history documentation for new features. I described proper usages of the YAML schema in detail, provided typical/useful examples, etc. You can find it here.

Migration guide​

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.

Deliverables​

• api-history.schema.json

  • A comprehensive YAML schema for documenting API history which includes support for:
    • 个添加
    • Deprecations
    • 更改
    • Links to relevant pull requests
    • Backports
  • Proposed in: electron/rfc#6
  • Implemented/Used in: electron/electron#42982
  • Used in: electron/website#594

• lint-markdown-api-history.ts

  • Script for linting YAML API history written according to a custom YAML (technically JSON) schema.
    • Useful error messages
    • Comprehensive documentation / code comments
    • Extensive Jest Vitest tests
    • Good performance
  • Implemented in: electron/lint-roller#73
  • Used in: 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
  • Implemented/Used in: electron/electron#42982

• api-history-migration-guide.md

  • Migration guide for new API history documentation system.
    • Easy to understand
    • Well written
    • Includes examples
  • Implemented/Used in: electron/electron#42982

结论​

I had a lot of fun working on this feature and was able to earn valuable experience from code reviews and discussing its various implementation details with the team.

I believe the addition of API history to the documentation will make the lives of developers using Electron a lot easier, especially ones attempting to migrate their existing app from a several year old Electron version.

I also want to sincerely thank my mentors:

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

...and the rest of the Electron team for answering my questions and taking the time to give me feedback on my pull requests. It is very much appreciated.

Electron 团队很高兴发布了 Electron 32.0.0！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

• 在我们的文档中添加新的 API 版本历史，一个由 @piotrpdev 创建的功能，作为Google Summer 代码的一部分。 You can learn more about it in this blog post. #42982
• 从 Web 文件 API 中移除非标准 File.path 扩展。 #42053
• 尝试打开受阻止路径中的文件或目录时，将 Web File System API 中的故障路径与上游对齐。 #42993
• 将以下现有的导航相关API添加到 webContents.navigationHistory : canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear。 旧的导航API现已被废弃。 #41752

架构（Stack）更新​

• Chromium128.0.6613.36
  • 128 新功能
  • 127 新功能
• Node 20.16.0
  • Node 20.16.0 博客
• V8 12.8

Electron 32 将 Chromium 从 026.0.6478.36 升级到 128.0.6613.36, Node 从 20.14.0 升级到 20.16.1 以及 V8 从 12.6 升级到 12.8。

新特性​

• 添加了对通过app模块的'login'事件，响应来自实用程序进程发起的认证请求的支持。 #43317
• 在CPUUsage结构中添加了cumulativeCPUUsage属性，该属性返回自进程启动以来使用的 CPU 时间的总秒数。 #41819
• 将以下现有的导航相关API添加到 webContents.navigationHistory: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear。 #41752
• 扩展 WebContentsView 以接受预先存在的 webContents 对象。 #42086
• 在nativeTheme中添加了一个新属性prefersReducedTransparency，该属性指示用户是否选择通过系统辅助功能设置来降低操作系统级别的透明度。 #43137
• 尝试打开阻塞路径中的文件或目录时，将文件系统访问 API 中的故障路径与上游对齐。 #42993
• 在 Linux 上启用 Windows 控制叠加层API。 #42681
• 在网络请求中启用 zstd 压缩。 #43300

重大更改​

移除: File.path​

Electron 的早期版本在 Web File 对象中添加了非标准 path 属性作为在渲染器中执行所有操作更为常见时处理本机文件的便捷方法。 然而它偏离了标准，并且也带来了较小的安全风险，因此从 Electron 32 开始它已被移除，取而代之的是 webUtils.getPathForFile 方法。

// Before (renderer)
const file = document.querySelector('input[type=file]');
alert(`Uploaded file path was: ${file.path}`);

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

// After (preload)
const { contextBridge, webUtils } = require('electron');

contextBridge.exposeInMainWorld('electron', {
  showFilePath(file) {
    // It's best not to expose the full file path to the web content if
    // possible.
    const path = webUtils.getPathForFile(file);
    alert(`Uploaded file path was: ${path}`);
  },
});

废弃：WebContents 中的 clearHistory, canGoBack, goBack, canGoForward, goForward, goToIndex, canGoToOffset, goToOffset​

在 WebContents 实例上与导航相关的API现在已被废弃。 这些API已被移动到WebContents的 navigationHistory 属性，以便为管理导航历史提供一个更有条理和直观的接口。

// Deprecated
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);

// Replace with
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);

Behavior changed: Directory databases in userData will be deleted​

If you have a directory called databases in the directory returned by app.getPath('userData'), it will be deleted when Electron 32 is first run. The databases directory was used by WebSQL, which was removed in Electron 31. Chromium now performs a cleanup that deletes this directory. See issue #45396.

终止对 29.x.y 的支持​

根据项目的支持政策，Electron 29.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

Electron 团队很高兴发布了 Electron 31.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

• 扩展 WebContentsView 以接受预先存在的 webContents 对象 #42319
• 添加了对 NODE_EXTRA_CA_CERTS 的支持。 #41689
• 更新了 window.flashFrame(bool) 以在 macOS 上持续闪烁。 #41391
• 移除了 WebSQL 支持。#41868
• nativeImage.toDataURL 将保留 PNG 颜色空间 #41610
• 扩展 webContents.setWindowOpenHandler 以支持手动创建 BrowserWindow。 #41432

架构（Stack）更新​

• Chromium126.0.6478.36
  • 126 新功能
  • 125 新功能
• Node 20.14.0
  • Node 20.14.0 博客
• V8 12.6

Electron 31 将 Chromium 从 114.0.6367.49 升级到 122.. 0.661.39, Node 从 20.11.2 升级到 20.14.0，V8 从 12.4 升级到 12.6。

新特性​

• 添加 clearData 方法支 Session. #40983
  • 添加参数到 Session.clearData API。 #41355
• 添加了对 navigator.serial 中的服务类ID请求的蓝牙端口的支持。 #41638
• 支持 Node's NODE_EXTRA_CA_CERTS 环境变量. #41689
• 扩展 webContents.setWindowOpenHandler 以支持手动创建 BrowserWindow。 #41432
• 实现了对 web 标准 File System API 的支持。 #41419
• 扩展 WebContentsView 以接受预先存在的 webContents 对象 #42319
• 在 webContents API 上添加了一个新的实例属性 navigationHistory，配合 navigationHistory.getEntryAtIndex 方法，使应用能够检索浏览历史中任何导航条目的 URL 和标题。 #41577 ^{(Also in 29, 30)}

重大更改​

移除: WebSQL 的支持​

Chromium has removed support for WebSQL upstream, transitioning it to Android only. 更多信息，请阅读 Chromium's 移除意图的讨论

行为变更：nativeImage.toDataURL 将保留 PNG 色彩空间。​

PNG 解码器已支持保留颜色空间数据。 从此函数返回的编码数据现在与预期结果匹配。

更多信息，请阅读 crbug.com/332584706。

行为变更：win.flashFrame(bool) 将在 macOS 上持续闪烁 Dock 图标。​

This brings the behavior to parity with Windows and Linux. 之前的行为：第一次调用 flashFrame(true) 只会使 Dock 图标弹跳一次 (使用 NSInformationalRequest level)，调用 flashFrame(false) 不会有任何效果。 现在的行为：持续闪烁，直到调用 flashFrame(false)。 使用了 NSCriticalRequest 级别替换。 如果要明确使用 NSInformationalRequest 使 Dock 图标弹跳一次，仍然可以使用 dock.bounce('informational').

终止对 28.x.y 的支持​

根据项目的支持政策，Electron 28.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

Electron 团队很高兴发布了 Electron 30.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

• Windows 现在支持 ASAR 完整性检查 (#40504)
  • 启用ASAR完整性的现有应用程序如果配置不正确，可能无法在Windows上工作。 使用 Electron 打包工具的应用应该升级到 @electron/packager@18.3.1 或 @electron/forge@7.4.0。
  • 查看我们的 ASAR Integrity 教程 以获取更多信息。
• 添加了 WebContentsView 和 BaseWindow 主进程模块，废弃并替换 BrowserView (#35658). Learn more about how to migrate from BrowserView to WebContentsView in this blog post.
  • BrowserView 现在是 WebContentsView 的一个壳，并且旧的实现已被移除。
  • 查看 我们的 Web Embeds 文档 以便将新的 WebContentsView API 和其他类似 API进行比较。
• 实现了对 File System API 的支持 (#41827)

架构（Stack）更新​

• Chromium 124.0.6367.49
  • Chrome 124 和 DevTools 124 中的新功能
  • Chrome 123 和 DevTools 123 中的新功能
• Node 20.11.1
  • Node 20.11.1 发布说明
• V8 12.4

Electron 30 将 Chromium 从 122.0.6261.39 升级到 124.0.6367.49, Node 从 20.9.0 升级到 20.11.1 以及 V8 从 12.2 升级到 12.4。

新特性​

• 在 webviews 中添加了 transparent 网页偏好设置。 (#40301)
• 在 webContents API 上添加了一个新的实例属性 navigationHistory，配合 navigationHistory.getEntryAtIndex 方法，使应用能够检索浏览历史中任何导航条目的 URL 和标题。 (#41662)
• 新增了 BrowserWindow.isOccluded() 方法，允许应用检查窗口是否被遮挡。 (#38982)
• 为工具进程中 net 模块发出的请求添加了代理配置支持。 (#41417)
• 添加了对 navigator.serial 中的服务类ID请求的蓝牙端口的支持。 (#41734)
• 添加了对 Node.js NODE_EXTRA_CA_CERTS 命令行标志的支持。 (#41822)

重大更改​

行为变更：跨源 iframe 现在使用 Permission Policy 来访问功能。​

跨域 iframe 现在必须通过 allow 属性指定一个给定 iframe 可以访问的功能。

有关更多信息，请参见 文档。

移除：--disable-color-correct-rendering 命令行开关​

此开关从未正式文档化，但无论如何这里都记录了它的移除。 Chromium 本身现在对颜色空间有更好的支持，因此不再需要该标志。

行为变更：BrowserView.setAutoResize 在 macOS 上的行为​

在 Electron 30 中，BrowserView 现在是围绕新的 WebContentsView API 的包装器。

以前，BrowserView API 的 setAutoResize 功能在 macOS 上由 autoresizing 支持，并且在 Windows 和 Linux 上由自定义算法支持。 对于简单的用例，比如使 BrowserView 填充整个窗口，在这两种方法的行为上是相同的。 然而，在更高级的情况下，BrowserViews 在 macOS 上的自动调整大小与在其他平台上的情况不同，因为 Windows 和 Linux 的自定义调整大小算法与 macOS 的自动调整大小 API 的行为并不完全匹配。 自动调整大小的行为现在在所有平台上都标准化了。

如果您的应用使用 BrowserView.setAutoResize 做的不仅仅是使 BrowserView 填满整个窗口，那么您可能已经有了自定义逻辑来处理 macOS 上的这种行为差异。 如果是这样，在 Electron 30 中不再需要这种逻辑，因为自动调整大小的行为是一致的。

移除：WebContents 上 context-menu 的 params.inputFormType 属性​

WebContents 的 context-menu 事件中 params 对象的 inputFormType 属性已被移除。 请改用新的 formControlType 属性。

移除：process.getIOCounters()​

Chromium 已删除对这些信息的访问。

终止对 27.x.y 的支持​

根据项目的支持政策，Electron 27.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。