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 から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、Bluesky や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更​

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

累積的変更​

• Chromium 146.0.7680.65

  • Chrome 146 の新機能
  • Chrome 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.

新機能と改善点​

• 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 ^{(及び 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 ^{(及び 39, 40)}
• Added support for the Node.js --experimental-transform-types flag. #49882 ^{(及び 39, 40)}
• Added support for long-animation-frame script attribution (via --enable-features=AlwaysLogLOAFURL). #49773 ^{(及び 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.

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

Electron チームは、Electron 40.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、Bluesky や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

累積的変更​

• Chromium 144.0.7559.60

  • Chrome 144 の新機能
  • Chrome 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.

新機能と改善点​

• Added "memory-eviction" as a possible reason for a child process to exit. #48362
• Added bypassCustomProtocolHandlers option to net.request. #48883 ^{(及び 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 ^{(及び 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 にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

最近、私は Electron と Chromium のウインドウのサイズ変更動作の改善に取り組みました。

バグ​

Windows では、ウインドウのサイズを変更すると以下のように古いフレームが表示されるという問題が発生していました。

このバグに特に興味深かった理由は何ですか？​

1. 挑戦的だった。
2. 大規模なコードベースの奥深くにあった。
3. 後でわかるように、内部には 2 つの異なるバグがあった。

バグの修正​

このようなバグの場合、最初の課題は調べ始めを把握することです。

Electron は、Google Chrome のオープンソース版である Chromium をベースに構築されています。 Electron をコンパイルするとき、Electron のソースコードがサブディレクトリとして Chromium のソースツリーに追加されます。 Electron は、最新ブラウザの機能を提供するためにそののほとんどを Chromium のコードに依存しています。

Chromium には約 3600 万行のコードがあります。 Electron も大きなプロジェクトです。 この問題の原因となる可能性のあるコードは大量にあります。

根本原因の絞り込み​

私は色々な実験をしてみました。

まず、Google Chrome でも以下のように問題が発生していることに気付きました。

これは、Electron ではなく Chromium で問題が発生している可能性を示唆しています。

さらに、macOS ではこの問題は示されませんでした。 これは Windows 固有のソースコードによることを示唆しています。

決定的な手がかり​

私はさまざまなコマンドラインフラグと構成オプションを試しました。

私は app.disableHardwareAcceleration() で問題が解決することに気付きました。 ハードウェアアクセラレーションをなくすと問題が消えたのです。

ここで背景を説明すると、Chromium は画面上にピクセルを表示するためのさまざまなグラフィックス API (OpenGL、Vulkan、Metal など) をサポートしています。 Windows では、macOS や Linux とは異なるグラフィックス API を使用しています。 また Windows であっても、Chromium は複数の異なるグラフィックスバックエンドを使用できます。

Chromium が使用するグラフィックスバックエンドは、ユーザーのハードウェアによって異なります。 例えば、一部のグラフィックスバックエンドではコンピュータに GPU が搭載されている必要があります。

さまざまなグラフィックスバックエンドを試したところ、以下のフラグで問題が解決したことに気付きました。

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

以下のフラグでは問題が再現されました。

• --use-angle=d3d11 (これは現在の、Windowsのデフォルトです)
• --use-angle=gl (WindowsではDirect3D 11へフォールバックします。「chrome://gpu/」を参照してください)

正常動作するようなフラグは、どれも Windows 上の Electron アプリでデフォルトとして使用できるほど十分なものではありません。 遅すぎるか、ドライバのサポートが手厚くありませんでした。

しかし、これらの回避策が道を照らすことになりました。 これらは問題が ANGLE Direct3D 11 バックエンドでのみ使用されるコードパスにあることを示していたのです。

Direct3D はハードウェアアクセラレーショングラフィックス用の Windows API です。

ANGLE は、OpenGL 呼び出しを、指定されたオペレーティングシステムのネイティブのグラフィックス API への呼び出し、ここでは Direct3D に変換するライブラリです。 ANGLE を使用すると、Chromium 開発者はすべてのプラットフォームで OpenGL 呼び出しを記述できます。 ANGLE は、使用されているグラフィックス API に応じてそれらを Direct3D、Vulkan、または Metal の API 呼び出しへ変換します。

関連する Chromium コンポーネントの特定​

Chromium は数万箇所で Direct3D を参照しています。 それらすべてを検討するのは現実的ではありませんでした。

偶然にも、Chromium のソースコードで役立つ以下のようなデバッグフラグをいくつか見つけました。

• --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
• (他にもたくさん)

これらは Chromium グラフィックのスタックのさまざまな部分によって再描画または更新されたブラウザウインドウの領域を強調表示してくれます。

これにより、グラフィックスのスタックのどの部分がどの出力を生成しているかを確認できるようになりました。

特に、--tint-composited-content と --tint-composited-content-modulate の組み合わせが非常に役立ちました。 前者は、コンポジッタの出力に色を付けます。 後者は、フレームごとの色付けを変更します。

スクリーンショットでは、シアン色のフレームが最後に描画されたフレームです。

そのフレームの右側のジャンクはシアン色になっていませんでした。 これは以前のフレームから残っていたさまざまな色が付いていました。 これは、ジャンクがコンポジッタから発生していないことを示しています。 コンポジッタは正しい出力を送っていました。

コンポジッタは Chromium のグラフィックスのスタックの一部です。 非常に簡略化していますが、このブログ記事の目的のために噛み砕くと以下のようにイメージするとよいでしょう。

1. コンポジッタ cc が、描画命令を含む CompositorFrame を生成します。
2. cc がその CompositorFrame をディスプレイコンポジッタ viz へ送信します。
3. viz はフレームを描画して画面に表示します。

各 CompositorFrame に色を付けることにより、コンポジッタは正しい出力を生成したことが示されました。 したがって、この問題はディスプレイコンポジターの viz にあるはずです。

関連する viz コードの特定​

そこから、私は viz ソースコード内で Direct3D が出てくる箇所を探し始めました。

注: ここからは、記事の内容が少し技術的になり、ソースコードのシンボルを参照し始めます。

ANGLE Direct3D 11 バックエンドでは、Chromium がウインドウのコンテンツを描画するために Windows の DirectComposition API を使用していることがわかりました。

Chromium の DirectComposition の OutputSurface は、Chromium の他のほとんどの出力サーフェスと異なります。 これには、supports_viewporter の機能があります (ソースリンク 1、ソースリンク 2)。

出力サーフェスは描画可能なビットマップであり、多くの場合 GPU テクスチャの中身です。

supports_viewporter がない場合、ウインドウサイズが変更されるたびに、Chromium は新しいウインドウサイズに一致する出力サーフェスを新規作成することになります。 そしてそのサーフェスに描画されて表示されます。

supports_viewporter は、このようなコストのかかるサーフェス割り当てを削減しようとします。 supports_viewporter では、Chromium はサイズ変更ごとに新しいサーフェスを割り当てません。 代わりに、描画が必要な領域よりも大きいサーフェスを割り当てています。 そして、そのサーフェスの特定の部分矩形 ("ビューポート") のみが画面上に描画され表示されます。 サーフェスの他の部分は画面に表示されません。

これにより、サイズ変更のたびに新しいサーフェスを割り当てるのではなく、Chromium がサーフェスを適切な幅と高さにパディングするだけで済むため、サイズ変更処理がより効率的になると考えられるからです。 このサーフェスのサイズ変更ロジックは direct_renderer.cc にあります。

つまり以下のようになっています。

説明すると、

• 青い長方形がサーフェスです。
• 緑色の領域はビューポート、つまり表示されることになっているサーフェスの領域であり、アクティブに描画する領域です。
• 赤い四角形はクリップ矩形、つまり実際に画面に表示されているサーフェスの部分です。

パフォーマンス最適化のため、新しいフレームを得る際にはビューポート (緑色の領域) のみが再描画されます。 残りは変わらないままです。 これは重要です。 緑色のビューポートのみを再描画しています。 ビューポートの外側の領域は更新されません。

ウインドウのサイズを変更する場合、アトミックなトランザクション (= まったく同時) でビューポート (= 画面に表示される領域) を再描画し、クリップ矩形を更新してサーフェスを新しいビューポートサイズにクリップする処理が行われるはずです。

サイズ変更後は、以下のようにならなければなりません。

ここで、2 つのバグのうちの 1 つ目のものに到達します。

1 つ目のバグ​

時々これらの操作が同期されなくなることがあります。 例えば、ビューポートが再描画される前にクリップ矩形が更新されることがあります。 すると、次のような結果が得られます。

緑色のビューポートには古いフレームがまだ表示されています。 しかしクリップ矩形は大きくなり、まだ再描画していないサーフェスの領域が表示されます。

ウインドウを初めてサイズ変更すると、これらの領域は黒になります。 2 回目のサイズ変更では、これらの領域は古いピクセル値で埋まっています。 そこに表示されるのは、私たちが以前その領域に描いたものです。

同様に、ウインドウを小さくしているときに、特定のエッジケースでクリップ矩形の更新前にビューポートを再描画することがありました。

すると、新しいフレームが小さくなり、新しいビューポートを超える領域は再描画されなかったため、クリップ矩形の一部にはまだ前のフレームが表示されます。

では、なぜこれらの操作は同期して行われないのでしょうか？

ここでは 2 つの異なる Windows API を使用しています。

• IDXGISwapChain1::Present1 — これにより画面上に新しいピクセルが表示され、新しいビューポートが更新されます。
• IDCompositionDevice::Commit — これによりクリップ矩形が更新されます。

理解しておくべき重要な点は、両方の関数は CPU 上で同期的に戻るということです。 しかし、GPU 上で非同期的に実行されるタスクは後でスケジュールされます。 Windows とそのサービス (DWM など) は、これらのタスクがいつどのような順序で実行されるかを決定します。 したがって、それらは非同期的に有効になり、必ずしも同じフレーム内で有効になるわけではありません。

残念ながら、Windows ではこれらの操作を同期する方法が提供されていません。 そのため、この問題を解決するには他の方法を見つける必要がありました。

Chromium のメンテナと評価した選択肢は以下の 2 つです。

1. サイズ変更時に、ビューポートの外側にある以前に描画された全領域を透明で塗る。 これにより、それらの領域は見えなくなります。 これで画面の乱れは修正されます。
2. サイズ変更を、IDXGISwapChain1 から、IDCompositionDevice::Commit で更新を同期する DirectComposition サーフェスに切り替える。 これでも画面の乱れは修正されます。

私たちは 1 つ目のオプションを選択しました。2 番目の選択肢よりもサイズ変更が高速だったからです。

私は最初の解決策を実装した パッチ を Chromium に導入しました。

メインのパッチの準備として、他に以下の 2 つのパッチも提出しました。

1. 1 つ目のもの は、メインパッチとの組み合わせると CI が失敗する原因となっていた既存コードのバグを修正しました。 これで Electron アプリと Chrome の起動も少し速くなりました。
2. 2 つ目 は、メインのパッチのコードレビューを容易にするために分割したものです。

2 つ目のバグ​

この 1 つ目のバグに加えて、ピクセルの古さに起因する 2 つ目のバグもありました。

つまり以下のようになっています。

ユーザーがウインドウのサイズを変更すると、Chromium は新しいウインドウサイズに合わせてウインドウの中身を再描画する必要があります。 これには時間がかかります。 新しいフレームをすぐに準備できません。

このようになるフレームの時系列を以下に示します。

サイズ変更中のある特定の時点で、Windows は「そのウインドウの幅は 1,000 ピクセルです」と知らせます。 しかし、ブラウザのコンポジッタが生成するフレームは遅れています。 最後に描画したフレームの幅は 600 ピクセルかもしれません。

これまで、Chromium はウインドウの幅が最後に描画したフレームの幅と一致しないフレームをスキップしていました。 このときはただウインドウを更新しないと決めています。

しかし、サイズ変更操作が完了するまでウインドウの内容がまったく更新されないことがよくあります。

そこで 2015 年 に誰かがこう決断しました。「どうしてこれらのフレームを表示しないのか？ ウインドウのサイズと完全には一致しないかもしれないが、少なくとも何かは表示できるだろう。」

これで溝が生じるようになるのですが、当時の溝は黒でした。 そのため以前の実装よりも優れていたのです。

10 年後に DirectComposition になって、この溝はしばしば古いピクセルで埋められるようになりました。

何が起こっていたのかを見てみましょう。

各フレームは複数の描画パスで構成されます。 これらの描画パスは、画面上に描く必要があるさまざまなものを表します。 複雑なビットマップから単色塗りの矩形まであります。

すべてのフレームにはルートの描画パスがあり、ルートの描画パスには他のすべての描画パスが含まれ、それらが結合されます。 (描画パスは木構造に配置され、ルートの描画パスはその木の根になります。)

そこで、サイズ変更によってウインドウの幅が 1,000 ピクセルであることがわかったとします。 したがって、出力サーフェスのビューポートも幅 1,000 ピクセルになるように調整します。 しかし、今受け取ったフレームの幅は 600 ピクセルしかありません。

2015 年からの最適化 により、ルートの描画パスの幅も 1,000 ピクセルへ変更されます。 しかし描画パスが実際に画面に描くものは変わりません。 これにはまだ幅 600 ピクセルの画像を描画する命令のみが含まれています。

つまり以下のようになっています。

黄色の領域は、フレームの描画パスが実際に何かを描画した領域です。 その幅は 600 ピクセルです。

しかし、緑色のビューポートと赤色のクリップ矩形の幅は 1,000 ピクセルです。 それが画面に表示される領域です。 (結局のところ、ルート描画パスの幅の属性は 1,000 ピクセルの全領域の再描画を要求していました。)

しかし右側 400 ピクセルに対する描画命令がなかったため、それらの領域は更新されませんでした。

最初のサイズ変更では、そこに黒いピクセルが表示されます。 (これはサーフェスの初期化色です。)

その後のサイズ変更では、その領域には以前に描画したものが表示されます。 古いピクセルが表示されることになります。

この問題の修正は crrev.com/c/7156576 で行いました。

この修正によりウインドウと異なるサイズのフレームを受信したときの動作が変更されます。 フレームのサイズ変更で古いピクセルを含む溝をつくる代わりに、ビューポートのサイズ変更 とクリップ矩形のサイズ変更をします。

受け取ったフレームのサイズに合わせてサーフェスをクリップします。 描画指示がある 600 ピクセルを超えるものは表示されません。

ほら、溝も古いピクセルももうありません！

パッチを Electron にバックポートする​

修正が Chromium に反映されたら、それを Electron にも反映する必要がありました。

main ブランチでは、Electron は Chromium のバージョンを継続的に更新します。 その結果、このパッチは Chromium ローリング PR で main にマージされました。

しかし、今 main にコミットしたものは約 3 か月後の Electron リリースに含まれるというだけです。 既存のリリースおよびプレリリースの ブランチ は、古いバージョンの Chromium を実行します。

そこで、次のステップはパッチを Electron 39 と Electron 40 にバックポートすることでした。

Electron は patches/chromium ディレクトリ で Chromium のパッチのリストを保持しています。 Chromium のパッチをバックポートするときは、ここにそれを追加します。 Electron のビルド時に、これらのパッチは Chromium のソースコードへ適用されます。

(一般論として、私たちは Chromium のパッチ数を少なく抑える](../docs/latest/development/patches#patch-justification) ように努めています。 すべてのパッチは、Chromium の更新でマージコンフリクトを引き起こす可能性があります。 パッチによるメンテナンスの負担は現実問題です。)

Electron 39 の バックポート PR はすぐにマージされました。 この修正は Electron 39.2.6 の一部となりました。 🎉

Electron 39.2.6 以降でウインドウのサイズを変更しても、古いピクセルは表示されなくなります。

(このパッチは Google Chrome Canary の一部でもあります。 これらは 2026 年 2 月にリリースされる安定版 Google Chrome の一部となる予定です。)

謝辞​

この作業に資金を提供して頂いた Plasticity に深く感謝します！

ご協力いただいた Chromium チームの Michael Tang 氏と Vasiliy Telezhnikov 氏に感謝します。

おわりに​

これは私がこれまで取り組んだ中で最も難しいバグでした (18 年間のソフトウェア開発で多くの難しいバグに取り組んできたけれど)。

しかし、これまで取り組んだ中で最も楽しいプロジェクトでもありました。

面白いと思った方は、Electron への貢献 をご検討ください！ 新人さん大歓迎です。

2020 年以来、12 月はプロジェクトメンテナが通常のメンテナンス業務から離れて休憩をとったり集中して作業したりする時期となっています。 この休暇は私たちが休息して来たる年に向けて元気を取り戻すのに役立ちます。

とはいえ、こういった 1 か月に及ぶ休止はオープンソースプロジェクトが健全な状態にあるからこそ実現できます。プロジェクトを継続的に推進してくださっているすべてのメンテナと外部貢献者の方々に感謝申し上げます。 ❤️

2025 年の総括​

今年を締めくくるにあたり、私たちが達成したプロジェクトのいくつかを紹介したいと思います。 2025 年に私たちが誇れることは次のとおりです。

• ⚛️ 6 つの Electron の新メジャーバージョンを、他すべての Chromium メジャーバージョンと並行するよう送り出しました。
• 🌿 Electron のビルドツールを Ninja から Chromium の新しい siso ビルドシステムに移行しました。これによりネイティブのリモートビルド実行サポートが追加されます。
• ✨ releases.electronjs.org ページを新しいデザインで改訂しました。
• ✅ 4 つの新しい RFCs を承認し、他に 2 つを electron/electron に実装しました。
• ☀️ 以下 2 つの新しい Google Summer of Code のプロジェクトを完了しました。
  • Devtron DevTools IPC トラッカー拡張機能が、npm install --save-dev @electron/devtron で利用できるようになりました。
  • Electron の BaseWindow モジュールの ウインドウ状態の保存/復元 API が RFC として承認され、Electron コアへの最終マージを待っています。
• 📦 すべての @electron/ npm パッケージにて、少なくとも Node 22 を必要とする ECMAScript モジュールとして最新化したメジャーバージョンをリリースしました。
• 🔒 npm エコシステムにおけるセキュリティインシデントを考慮して、パッケージの公開を 継続的認証 から新しいトークンレス OIDC ベースの 信頼された頒布 システムに移行しました。
• 🧑‍💻 5 人の新しいメンテナーが加わりました。これから毎日素晴らしいソフトウェアを送り出してプロジェクトを長期にわたって運営してくれるでしょう。

素晴らしい年をありがとうございました。2026 年に会いましょう！

安息期間ポリシー​

前年から大きな変更はありませんが、期待を和らげつつメンテナが望む限りプロジェクトに関われるように、Issue とプルリクエストのレビューに関する文言を一部変更しました。

12 月でも変わらないこと​

1. ゼロデイやその他の主要なセキュリティ関連のリリースは必要に応じて公開されます。 セキュリティインシデントは、SECURITY.md ドキュメントに記載されているエスカレーションポリシーを通じて報告されるべきです。
2. 行動規範 における通報とモデレーションは継続されます。

12 月で変わること​

1. Electron 37、38、39 を含む、最後の安定ブランチのリリースは、12 月 1 日の週に行われます。 12 月中にこれ以上のリリース予定はありません。
2. 12 月の最後の 2 週間は、ナイトリー、アルファ、ベータのリリースを行いません。
3. ワーキンググループ の定例会は一時停止されます。
4. Issue のトリアージは遅れることがあります。
5. プルリクエストのレビューとマージは遅れることがあります。

Electron チームは、Electron 39.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、Bluesky や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更​

ASAR 整合性が安定版に​

長年「実験的」機能だったASAR 整合性は、Electron 39 で安定版になりました。 この機能を有効にすると、パッケージされた app.asar が実行時にビルド時のハッシュに対して検証され、改ざんを検出します。 ハッシュが存在しない場合、またはハッシュが一致しない場合は、アプリが強制終了します。

ASAR 整合性のドキュメント から、この機能がどのように機能するか、アプリケーションにどのように活用するか、Electron Forge や Electron Packager でどのように使用するかといった、詳細な情報をご覧いただけます。

関連して、Electron Packager v19 はデフォルトで ASAR が有効になります。 #1841

累積的変更​

• Chromium 142.0.7444.52
  • Chrome 142 の新機能
  • Chrome 141 の新機能
• Node 22.20.0
  • v22.20.0 のお知らせ
  • v22.19.0 のお知らせ
• V8 14.2
  • V8 roll increment

Electron 39 では、Chromium は 140.0.7339.41 から 142.0.7444.52 へ、Node は 22.18.0 から 20.0.0 へ、V8 は 14.0 から 14.2 へとアップグレードしています。

新機能と改善点​

• app.isHardwareAccelerationEnabled()を追加しました。 #48680
• オフスクリーンレンダリングに scRGB HDR 色空間をサポートする「RGBAF16」出力フォーマットを追加しました。 #48504
• より詳細なアクセシビリティサポート管理を有効にするためのメソッドを追加しました。 #48625
• USBDevice.configurations のサポートの追加しました。 #47459
• systemPreferences.getAccentColor を使用して Linux 上のシステムアクセントカラーを取得する機能を追加しました。 #48628
• 特定のセッション内でファイルシステム API の権限状態を保持できるようにしました。 #48326 ^{(及び 37, 38)}
• コンテキスト分離されていないプリロードで動的ESMインポートをサポートしました。 #48488 ^{(及び 37, 38)}
• ASAR 整合性 機能を安定版としてマークしました。 以前まで実験的機能でした。 #48434

破壊的変更​

非推奨： --host-rules コマンドラインスイッチ​

Chromium は --host-rules スイッチを非推奨にしています。

代わりに --host-resolver-rules を使用してください。

動作変更：window.open ポップアップが常にリサイズ可能に​

現行の WHATWG 仕様 では、window.open API はいかなる場合において、リサイズ可能なポップアップウィンドウを作成するようになりました。

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

動作変更：共有テクスチャ OSR paint イベントデータ構造​

共有テクスチャオフスクリーンレンダリング機能を使用する際、paint イベントがより構造化されたオブジェクトを発行するようになりました。 これにより、sharedTextureHandle、planes、modifier が統一された handle プロパティにまとめられました。 詳細については、OffscreenSharedTexture のドキュメント をご覧ください。

36.x.y サポートの終了​

プロジェクトの サポートポリシー に則り、Electron 36.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

Electron チームは、Electron 38.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、Bluesky や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

累積的変更​

• Chromium 140.0.7339.41
  • Chrome 140 の新機能
  • Chrome 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 へとアップグレードしています。

新機能と改善点​

• システムアクセントカラーのカスタマイズと、アクティブなウィンドウの枠線の強調表示をサポートしました。 #47285 (及び 37)
• macOS の process.getSystemMemoryInfo() に fileBacked と purgeable フィールドを追加しました。 #48146 (及び 37)
• macOS 上で起動時に Tray アイコンが位置を維持できるように、 guid コンストラクタオプションをサポートしました。 #48077 (及び 37)
• frameToken から WebFrameMain を取得できるように、 WebFrameMain.fromFrameToken(processId, frameToken) を追加しました。 #47942
• Windows と macOS に app.getRecentDocuments() のサポートを追加しました。 #47924 (及び 37)
• アセットやリソースの場所を特定するために、内部的に DIR_ASSETS ではなく DIR_MODULE/DIR_EXE を使用するように変更し、app.getPath で要求できる名前として「assets」を追加しました。 #47950 (及び 37)
• dialog.showMessageDialog が親ウィンドウを渡したときに、モニターの中心に誤ってウィンドウが表示される問題を修正しました。 #48215
• macOS で loadURL を介して読み込まれた Web ページをユーザが操作できなかった問題を修正しました。 #47575

破壊的変更​

Removed: macOS 11 support​

macOS 11 (Big Sur) は 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.

削除: ELECTRON_OZONE_PLATFORM_HINT 環境変数​

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

Linux の Wayland セッションで起動すると、Electron はデフォルトでネイティブの Wayland アプリとして実行されるようになりました。 一部の機能と API は Wayland と X11 では動作が異なる場合があります。 --ozone-platform=x11 フラグを追加することで、古いバージョンのように、X11 互換モード（Xwayland）で Electron を強制的に実行することができます。

削除: plugin-crashed イベント​

webContents から plugin-crashed イベントが削除されました。

非推奨: webFrame.routingId プロパティ​

routingId プロパティは将来的に webFrame オブジェクトから削除されます。

代わりに webFrame.frameToken を使用してください。

非推奨: webFrame.findFrameByRoutingId(routingId)​

webFrame.findFrameByRoutingId(routingId) 関数は将来的に削除されます。

代わりに webFrame.findFrameByToken(frameToken) を使用してください。

Google Summer of Code 閉幕​

私たちの 2 人の Google Summer of Code コントリビューターが夏のプロジェクトを完了しました！

• @nilayarya は Electron コアで新しい ウィンドウ状態の保存/復元 API を作成しました。 この新しい API は、ウインドウの状態の永続化処理のための組み込みで標準化された方法を提供します。 electron/rfcs#16 で Nilay のオリジナルの RFC を参照してください。
• @hitarth-gg は Chrome Manifest V3 API を使用して、長期休止状態の Devtron 拡張機能の近代化に多大な労力を費やしました。 このプロジェクトは、開発者が IPC 通信のデバッグ、イベントリスナーの追跡、および Electron アプリケーション内のモジュールの依存関係を視覚化するためのツールを提供します。

彼らのプロジェクトと成果について、より詳しいブログ記事を近日公開予定。

35.x.y サポートの終了​

プロジェクトの サポートポリシー に則り、Electron 35.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

Electron チームは、Electron 37.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、Bluesky や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

Google Summer of Code の開始​

2 人の Google Summer of Code の貢献者がプログラムのコーディング期間を開始しました！

• @nilayarya は Electron コアで新しい ウィンドウ状態の保存/復元 API を作成しています。 この新しい API は、ウインドウの状態の永続化処理のための組み込みで標準化された方法を提供します。 electron/rfcs#16 で Nilay さんの進行中の RFC を参照してください。
• @hitarth-gg は、Chrome Manifest V3 API を使用して、長らく休止状態にあった Devtron 拡張機能を最新化することに熱心に取り組んでいます。 このプロジェクトは、開発者が IPC 通信のデバッグ、イベントリスナーの追跡、および Electron アプリケーション内のモジュールの依存関係を視覚化するためのツールを提供します。

GSOC 参加者にとってこの数週間は刺激的な日々でした。今後の更新情報もご期待ください！

注目すべき変更​

滑らかな角: ネイティブ CSS のスクワークル​

Electron 37 では、カスタムの -electron-corner-smoothing CSS プロパティが導入され、アプリは Apple の macOS デザイン言語に合わせたより滑らかな丸角を作成できるようになりました。 この機能はもともと Electron 36 に搭載されていましたが、もっと注目されるべき機能だと感じました。

角スムージング 100% の例

コード	結果
.box { width: 128px; height: 128px; border-radius: 24px; -electron-corner-smoothing: 100%; }

長方形から四分円の角を削り出す標準の border-radius プロパティとは異なり、 -electron-corner-smoothing は連続した縁を持つ 四角形 状で曲線をスムーズに遷移させます。

0% から 100% までの値を使用して滑らかさを調整したり、system-ui 値を使用してオペレーティングシステムのスタイルに一致させたりできます (macOS では 60%、それ以外の場合は 0%)。 このデザイン強化は、境界線、アウトライン、影にも適用でき、アプリに絶妙な上品さを加えることができます。

累積的変更​

• Chromium 138.0.7204.35
  • Chrome 138 の新機能
  • Chrome 137 の新機能
• Node 22.16.0
  • Node 22.16.0 ブログ記事
• V8 13.8

Electron 37 では、Chromium は 136.0.7103.48 から 138.0.7204.35 へ、V8 は 13.6 から 13.8 へアップグレードしています。

新機能と改善点​

• window.openにinnerWidthとinnerHeightオプションを追加しました。 #47039 (及び 35, 36)
• webContents でマウスイベントを傍受および阻害するために、before-mouse-event を追加しました。 #47364 (及び 36)
• scriptURL プロパティを ServiceWorkerMain に追加しました。 #45863
• macOS >= 14.4 向けにメニューの sublabel 機能を追加しました。 #47042 (及び 35, 36)
• HIDDevice.collectionsのサポートの追加しました。 #47483 (及び 36)
• --no-experimental-global-navigatorフラグのサポートを追加しました。 #47418 (及び 35, 36)
• Linux X11でscreen.dipToScreenPoint(point)とscreen.screenToDipPoint(point)のサポートを追加しました。 #46895 (及び 35, 36)
• macOS 向けにメニュー項目のロール palette と header のサポートを追加しました。 #47245
• Node のオプション --experimental-network-inspection のサポートを追加しました。 #47031 (及び 35, 36)
• 開発者がウインドウの保護状態を確認できるように win.isContentProtected() を公開しました。 #47310 (及び 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);
});

動作変更: process.exit() がユーティリティプロセスを同期的に強制終了するように​

ユーティリティプロセスで process.exit() を呼び出すと、ユーティリティプロセスを同期的に強制終了するようになりました。 これにより、process.exit() の動作が Node.js の動作と一致するようになります。

process.exit() の前に console.log() を呼び出す場合等の潜在的な影響を理解したい方は、Node.js のドキュメント と PR #45690 をご参照ください。

Behavior Changed: WebUSB and WebSerial Blocklist Support​

WebUSB と Web Serial は、Chromium で使用されてそれぞれの仕様で概説されている、WebUSB ブロックリスト と Web Serial ブロックリスト をサポートするようになりました。

これらを無効化するには、ユーザーがコマンドラインフラグとして disable-usb-blocklist と disable-serial-blocklist を渡すことでできます。

削除: ProtocolResponse の session プロパティの null 値​

This deprecated feature has been removed.

以前は、ProtocolResponse.session プロパティに null をセットするとランダムな独立したセッションが作成されていました。 This is no longer supported.

単一目的のセッションを使用するためにこうすることは、オーバーヘッドがかかるため非推奨です。しかしこの動作を維持する必要がある古いコードでは、session.fromPartition(some_random_string) でランダムなセッションを作成し ProtocolResponse.session でそれを使用するようにすることで、この動作を再現できます。

動作変更: Linux 向けの BrowserWindow.IsVisibleOnAllWorkspaces()​

BrowserWindow.IsVisibleOnAllWorkspaces() は、そのウインドウが現在表示されていない場合 Linux 上で false を返すようになりました。

34.x.y サポートの終了​

プロジェクトの サポートポリシー に則り、Electron 34.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

Electron チームは、Electron 36.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、Bluesky や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更​

作文ツールサポート​

Electron 36 では、コンテキストメニューでの作文ツール (スペルと文法)、自動入力、サービスメニュー項目など macOS システムレベルの機能を有効化できます。 これを行うには、WebFrameMain のインスタンスを menu.popup() の frame 引数に渡します。

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

累積的変更​

• Chromium 136.0.7103.48
  • Chrome 136 の新機能
  • Chrome 135 の新機能
• Node 22.14.0
  • Node 22.14.0 ブログ記事
• V8 13.6

Electron 36 では、Chromium は 134.0.6998.23 から 136.0.7103.48 へ、Node は 13.5 から 13.6 へアップグレードしています。

新機能と改善点​

• 特定のウインドウがスナップで配置されているかを示す BrowserWindow.isSnapped() を Windows 向けに追加しました。 #46226
• フォーカスされたフレームを取得する WebContents.focusedFrame を追加しました。
• WebContents.opener の型を null になりうる型へ修正しました。 #45667
• 遅延読み込みの構成に ffmpeg.dll を追加しました。 #46173 (及び 34, 35)
• システムテーマとアプリテーマを区別できる nativeTheme.shouldUseDarkColorsForSystemIntegratedUI を追加しました。 #46598 (及び 35)
• webRequest フィルターに excludeUrls を追加し、urls プロパティでの空配列の使用を非推奨化しました。 #44692 (及び 35)
• menu.popup の新しい frame オプションを介して、コンテキストメニューの自動入力、作文ツール、サービスなど macOS レベルのメニュー項目のサポートを追加しました。 #46350
• Linux 向けに system-context-menu のサポートを追加しました。 #46399
• Windows 向けに ASAR の整合性検査を改善しました。 #46537
• macOS 向けにサムネイルを要求しないときの desktopCapturer.getSources のパフォーマンスが向上しました。 #46251 (及び 34, 35)
• 共有テクスチャ OSR 使用時の 240 FPS 制限を除去しました。 #45669 (及び 35)

破壊的変更​

非推奨化: NativeImage.getBitmap()​

NativeImage.getBitmap() 関数は非推奨となり、NativeImage.toBitmap() のエイリアスであると文書化されました。 2 つの関数はどちらもビットマップの新しく確保したコピーを返し、機能的に同等です。

非推奨化: session の拡張機能のメソッドとイベント​

session.loadExtension、session.removeExtension、session.getExtension、 session.getAllExtensions、およびイベント extension-loaded、 extension-unloaded、extension-ready はすべて、session.extensions インスタンスプロパティからアクセスできる新しい Extensions オブジェクト へ移動されました。

削除: session.clearStorageData(options) の quota のタイプ syncable​

session.clearStorageData(options) を呼び出す際の options.quota のタイプ syncable は、上流の Chromium から 削除 されたためサポートされなくなりました。

非推奨化: session.clearStorageData(options) の quota プロパティ​

Session.clearStorageData(options) を呼び出すときの、options.quota プロパティは非推奨になります。 syncable タイプは削除されたため残ったタイプは 'temporary' のみであり、これの指定は不要です。

動作変更: GTK 4 が GNOME で実行する場合のデフォルトに​

上流の変更 により、GNOME で実行する場合のデフォルトが GTK 4 になりました。

まれに、これにより一部のアプリケーションまたは構成で以下のメッセージを伴う エラー が発生する場合があります。

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

影響を受けるユーザーは gtk-version のコマンドラインフラグを以下のように指定することで回避できます。

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

app.commandLine.appendSwitch 関数でも同様のことができます。

動作変更: app.commandLine​

app.commandLine は大文字のスイッチと引数を小文字へ変換するようにします。

app.commandLine は Chromium のスイッチ (大文字小文字の区別なし) を処理することのみを目的としており、app.commandLine 経由で渡されるスイッチはどの子プロセスにも渡されません。

アプリ固有のコマンドライン引数を解析するために app.commandLine を使用していた方は、process.argv 経由でこれを行うようにすべきです。

33.x.y サポートの終了​

プロジェクトの サポートポリシー に則り、Electron 33.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

Electron チームは、Electron 35.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、Bluesky や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更​

拡張機能サポートの改善のためのサービスワーカーのプリロードスクリプト​

もともと RFC #8 で @samuelmaddock によって提案されていたもので、Electron 35 にて サービスワーカー にプリロードスクリプトをアタッチする機能を追加します。 Chrome の Manifest V3 拡張機能では多くの機能が 拡張機能のサービスワーカー を通じて提供されるため、この機能は Electron と最新の Chrome 拡張機能との間のサポートに関するギャップを埋めます。

Session のレベルでプログラムでプリロードスクリプトを登録する場合、ses.registerPreloadScript(script) API でそれをサービスワーカーのコンテキストへ指定し適用できるようになりました。

// セッションにプリロードレルムスクリプトを追加します。
session.defaultSession.registerPreloadScript({
  // スクリプトはサービスワーカーのプリロードレルムでのみ実行されるべきです。
  type: 'service-worker',
  // スクリプトへの絶対パス。
  script: path.join(__dirname, 'extension-sw-preload.js'),
});

さらに、ServiceWorkerMain.ipc のインスタンスを介して、サービスワーカーとそれにアタッチされたプリロードスクリプトの間で IPC が利用できるようになりました。 プリロードスクリプトは引き続き ipcRenderer モジュールでもサービスワーカーと通信できます。 詳細は元の RFC をご参照ください。

この機能の実装前に、以下の前提となる他多くの変更が行われました。

• #45329 で Session モジュールのプリロード API を再設計し、個々のプリロードスクリプトの登録と解除をサポートするようになりました。
• #45229 でコンテキストブリッジを介してメイン ワールドで JavaScript を評価するための実験的なスクリプト contextBridge.executeInMainWorld(executionScript) が追加されました。
• #45341 でメインプロセスでサービスワーカーとやり取りするための ServiceWorkerMain クラスが追加されました。

累積的変更​

• Chromium 134.0.6998.44
  • Chrome 134 の新機能
  • Chrome 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 を追加してアプリの設定から「内蔵カメラの下に収まるようにサイズ調整」を削除しました。 #45357 ^{(同じく v34.1.0)}
• メインプロセスでサービスワーカーとやり取りするための ServiceWorkerMain クラスを追加しました。 #45341
  • サービスワーカーの実行状態が変化したことを表すために、ServiceWorkers に running-status-changed イベントを追加しました。
  • 以前に停止された可能性のあるワーカーを起動するために、ServiceWorkers に startWorkerForScope を追加しました。
• ワールドの境界を越えてコードを安全に実行するための実験的な contextBridge.executeInMainWorld を追加しました。 #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 向けに BrowserWindow コンストラクタのオプション roundedCorners のサポートを追加しました。 #45740 ^{(同じく v34.3.0)}
• サービスワーカーのプリロードスクリプトのサポートを追加しました。 #45408
• Portal の globalShortcuts をサポートします。 この機能を動作させるには、Electron を --enable-features=GlobalShortcutsPortal で実行する必要があります。 #45297

破壊的変更​

削除: PrinterInfo の isDefault プロパティと status プロパティ​

これらのプロパティは上流の Chromium から削除されたため、PrinterInfo オブジェクトからも削除されました。

非推奨化: session.serviceWorkers の fromVersionID​

session.serviceWorkers.getInfoFromVersionID(versionId) の代わりに session.serviceWorkers.fromVersionID(versionId) API は非推奨化されました。 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 からは 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 にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

詳細については、Google の Summer of Code のホームページ をご覧ください。

私たちについて​

Electron は、ウェブ技術を用いたクロスプラットフォームのデスクトップアプリケーションを構築する JavaScript フレームワークです。 Electron フレームワークのコアは Chromium と Node.js で構築されたコンパイル済みバイナリ実行形式であり、主に C++ で書かれています。

Electron のコア リポジトリ以外では、Electron エコシステムをサポートするいくつかのプロジェクトを管理しています：

• エンドユーザの頒布ツール (例えば Electron Forge や update.electronjs.org)。
• Electron 開発者向けの学習教材 (例えば electronjs.org や Electron Fiddle)。
• 開発者の生産性を効率化する内部ツール (例えば Electron Build Tools や Sheriff)。

GSoC 貢献者となって、github.com/electron 傘下の多くのプロジェクトのうちの 1 つで Electron のコア貢献者と共同作業する機会が得られます。

応募する前に​

Electron にあまり詳しくない方は、ドキュメント を読んだり、Electron Fiddle のサンプルを試してみることをお勧めします。

Electron アプリの頒布について学びたい方は、以下のようにして Electron Forge 付きのサンプルアプリケーションを作成してみてください。

npm init electron-app@latest my-app

コードに少し慣れたら、Electron の Discord サーバー での会話にご参加ください。

プロジェクトの貢献者​

あなたが興味のあるプロジェクトのアイデアに関連するリポジトリを見てみることをお勧めします。 あなたの研究を行う一つの方法は、バグを報告したり、 既存の問題をトリアージしたり、プルリクエストを送信したりすることです。 そうすることはコードベースで実践的な練習をする効果的な方法ですが、提案の提出には必須ではありません。 よく検討された提案は、過去のコントリビューションを参照することなくコードへの理解度を実証できるものである必要があります。

Electronへの貢献を検討されている場合は、提案を提出する前に以下のヒントを参考にしてください。

1. コントリビューションを送信する際は、わかりやすいイシューやプルリクエストの説明を記入してください。 コードの中身に関わらず、貢献の執筆に力を入れると共同作業の環境で効果的なコミュニケーションを発揮できるでしょう。
2. 開かれている Issue に対する PR はいつでも歓迎します。 メンテナへその Issue にアサインしてもらうよう求めるコメントは不要です。 解決策のアイデアを洗練させる必要がある場合は、問題に対する潜在的な解決策について話し合うことを引き続き推奨します。しかし注意として、何かに取り組めるかどうかをつぶさに尋ねるコメントは冗長で、Issue トラッカーにノイズを加えることになります。
3. あまり労力されていないプロジェクト貢献 (無効な Issue 報告、リポジトリの README への些細な文言の変更、フロントエンドコードのスタイル上の小さな変更など) はあなたの最終的な提案に悪影響を及ぼします。メンテナの限られた時間を奪い、Electron プロジェクトに純粋な利益をもたらさないためです。
4. AI コーディングアシスタントはデバッグや新しい概念の理解に効果的なツールですが、AI 生成の出力を直接コピー/ペーストした貢献は強く推奨されません。 これらはしばしば品質が低く、メンテナが LLM 生成コードをきれいにする方が PR をまとめて拒否するよりも手間なことがよくあります。

提案の作成​

Electron との共同開発に興味を持てましたか? 最初に、準備されている7つのプロジェクトアイデア案をご覧ください。 リストにあるすべてのアイデアは、提案可能です。

リストにないユニークなアイデアをお持ちの場合には検討いたしましが、提案内容が詳細かつ十分に整理されていることを確認してください。 あまり自信がないのであれば、リストのアイデアに従うことをお勧めします。

応募には以下のものがあるとよいでしょう。

• 夏に達成する予定の内容をまとめた詳細な提案書。
• 開発者としての経歴。 履歴書がある場合は、コピーを添付してください。 それ以外の場合は、過去の技術経験についてお教えください。
  • 特定の分野での経験不足で不合格になることはありませんが、これはメンターがあなたを最も効果的にサポートし、サマープロジェクトが成功するよう計画を立てるのに役立ちます。

Electronアプリケーションの一部として提出する必要のある項目の詳細なガイドはこちらをご確認ください。 Google Summer of Codeポータルに直接提案を送信する。 Electron チームへ電子メールで送信された提案は、最終提出物とみなされません。

提案に関する詳細なガイダンスについては、こちらの Google Summer of Code 公式の提案作成アドバイス に従うことをお勧めします。

応募開始は 2025 年 3 月 24 日、締め切りは 2025 年 4 月 8 日 です。

質問?​

ブログ記事で取り上げられていない質問や提案の執筆に関するお問い合わせは、summer-of-code@electronjs.org までメールしていただくか、GSoC FAQ をご確認ください。 メールを送る前に、 コントリビューターガイダンスをお読みください。

リソース​

• 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 から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、Bluesky や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更​

HTTP 圧縮における共有辞書管理 API​

HTTP 圧縮は、ブラウザがデータを受信する前に、Web サーバーによってデータを圧縮することを可能にします。 最新バージョンの Chromium は Brotli や Zstandard などの新しい圧縮アルゴリウムをサポートしており、テキストファイルに対して gzip などの従来方式よりも優れた性能を発揮します。

カスタム圧縮辞書は Brotli や Zstandard の圧縮効率をさらに向上させます。 詳細は共有辞書についてのChrome for Developers ブログをご覧ください。

@felixrieseberg は #44950 に以下の API を追加し、セッションレベルで共有辞書を管理できるようになりました。

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

応答しないレンダラーのJavaScriptコールスタック​

レンダラープロセスが規定の時間以上ハングした場合、Electron の unresponsive イベントが発生します。 @samuelmaddock が #44204 で追加した新しい webFrameMain.collectJavaScriptCallStack() API は、関連する WebFrameMain オブジェクト（webContnets.mainFrame）から JavaScript のコールスタックを収集できるようにします。

この API は、JavaScript イベントが長時間実行され、プロセスがハングした場合にフレームが応答しなくなる原因を特定するのに役立ちます。 詳細はクラッシュレポート API の Web 標準への提唱をご覧ください。

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

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

app.on('web-contents-created', (_, webContents) => {
  webContents.on('unresponsive', async () => {
    // 応答しないレンダラーの実行を中断し、コールスタックを収集する
    const callStack = await webContents.mainFrame.collectJavaScriptCallStack();
    console.log('Renderer unresponsive\n', callStack);
  });
});

[! 注意] このAPIはヘッダーに 'Document-Policy': 'include-js-call-stacks-in-crash-reports' を追加して、有効化する必要があります。 詳しい情報は #45356 を参照してください。

累積的変更​

• Chromium 132.0.6834.83
  • Chrome 131 の新機能
  • Chrome 132 の新機能
• Node 20.18.1
  • Node 20.18.1 ブログ記事
• V8 13.2

Electron 34 では、130.0.6723.44 から 132.0.6834.83 へ、Node は 20.18.2 から 20.18.1 へ、V8 は 13.0 から 13.2 へとアップグレードしています。

新機能​

• Brotli または ZStandard を使用して圧縮効率を向上するための、共有辞書を管理する API を追加しました。 新しい session.getSharedDictionaryUsageInfo()、session.getSharedDictionaryInfo(options)、session.clearSharedDictionaryCache()、session.clearSharedDictionaryCacheForIsolationKey(options) APIを追加しました。 #44950
• WebFrameMain.collectJavaScriptCallStack() を追加し、応答しないレンダラーの JavaScript コールスタックにアクセスすることができるようになりました。 #44938
• フレームのアンロード状態に WebFrameMain.detached を追加しました。
  • フレームが破棄されたかどうかを判断するために WebFrameMain.isDestroyed() が追加されました。
  • フレームのアンロード中に、WebFrameMain.fromId(processId, frameId) が与えられたパラメータと一致しないインスタンスを返すのを修正しました。 #43473
• V8 の致命的なエラーに関する診断レポートをサポートするために、ユーティリティプロセスにエラーのイベントを追加しました。 #43774
• 機能：GPUアクセラレーションによる共有テクスチャのオフスクリーンレンダリングを追加。 #42953

破壊的変更​

動作変更: Windows では、全画面表示中にメニューバーが非表示になります。​

これにより、Linux と同等の動作になります。 以前までは、Windows では全画面表示中にメニューバーが表示されていました。 これからは、Windows では全画面表示中にメニューバーが隠れます。

訂正: これは以前、Electron 33 で破壊的変更として記載されていましたが、Electron 34 で最初にリリースされました。

31.x.y サポートの終了​

プロジェクトの サポートポリシー に則り、Electron 31.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

どういう意味ですか？​

これまで、Electron の npm エコシステム (Forge、Packager など) のパッケージは、その Node バージョンのサポート終了 (EOL) 日が過ぎた後でも、可能な限りそのバージョンをサポートしてきました。 これは、エコシステムが断片化されないようにするためです。多くのプロジェクトが古いバージョンの Node に依存していることを理解していますが、アップグレードする緊急の理由がなかっただけでそれらのプロジェクトが取り残されるリスクを冒したくありません。

時間の経過とともに、Node.js 14 を最小バージョンとして使用することが、以下の理由によりますます困難になってきました。

• 公式の Node.js 14 は macOS ARM64 ビルドがないため、完全なテストカバレッジを提供するために CI インフラストラクチャでの回避策をメンテンナンスする必要があります。
• 上流パッケージの依存関係に対する engines の要件が進み、依存関係の増加によるサプライ チェーンのセキュリティ問題を解決することがますます困難になっています。

さらに、Node.js の新しいバージョンには、ランタイムネイティブの共通ユーティリティ (例: fs.glob や util.parseArgs) や、付属の新規モジュール (例: node:test、node:sqlite) など、活用したい多くの改善点が含まれています。

なぜ今アップグレードするのですか？​

2024 年 7 月、Electron のエコシステムワーキンググループは、そのバージョンが LTS の日付に達した後の将来、同期的な ESM グラフの require() がサポートされる最初の Node バージョンで全パッケージをアップグレードすることを決定しました (nodejs/node#51977 および nodejs/node#53500 を参照)。

このアップデート時期は 2025 年 1 月 / 2 月に設定しました。 このアップグレードが行われると、Node 22 が既存のエコシステムパッケージでサポートされる最小バージョンになります。

自分に必要なアクションは何ですか？​

私たちは可能な限り互換性を維持するよう努めています。 しかし、最適なサポートを確実に受けるためにアプリを Node 22 以降へアップグレードすることを推奨します。

注意として、プロジェクトを実行している Node のバージョンは現在の Electron バージョンに組み込まれている Node のバージョンと無関係です。

今後の予定​

ご質問やご不明な点がありましたら、info@electronjs.org まで気軽にお問い合わせください。 公式の Electron の Discord でコミュニティのサポートも得られるでしょう。

GIPHY より

12 月でも変わらないこと​

1. ゼロデイやその他の主要なセキュリティ関連のリリースは必要に応じて公開されます。 セキュリティインシデントは、SECURITY.md に則って報告してください。
2. 行動規範 における通報とモデレーションは継続されます。

12 月で変わること​

1. Electron 31、32、33 を含む、2024 年の最後の安定ブランチのリリースは、12 月 1 日の週に行われます。 12 月中にこれ以上のリリース予定はありません。
2. 12 月の最後の 2 週間は、ナイトリーやアルファのリリースはありません。
3. いくつかの例外を除いて、プルリクエストのレビューやマージはしません。
4. どのリポジトリでも Issue トラッカーは更新されません。
5. メンテナからの Discord デバッグのヘルプはありません。
6. ソーシャルメディアコンテンツの更新はありません。

皆さん、2025 年にまたお会いしましょう!

Electron は、Chromium の UI フレームワークである Views API に合わせて、BrowserView から WebContentsView へ移行しています。 WebContentsView は、Chromium のレンダリングパイプラインに直接結び付けられた再利用可能なビューを提供し、将来のアップグレードを簡素化し、開発者が Electron アプリに非ウェブ UI 要素を統合する可能性を広げます。 WebContentsView を採用することで、アプリケーションは今後のアップデートに備えることができるだけでなく、長期的にはコードの複雑さが軽減され、潜在的なバグも減少するというメリットも得られます。

BrowserWindow と BrowserView に精通している開発者は、BrowserWindow と WebContentsView がそれぞれ BaseWindow と View の基底クラスから派生したサブクラスであることに注意するとよいでしょう。 利用可能なインスタンス変数とメソッドを完全に理解するには、これら基底クラスのドキュメントを参照するようにしてください。

移行ステップ​

1. Electron 30.0.0 以降へアップグレード​

2. あなたのアプリケーションが BrowserView を使う場所を把握する​

1 つ方法は、あなたのコードベースで new BrowserView( を検索することです。 これにより、アプリケーションが BrowserView をどのように使用しているか、および移行する必要がある呼び出し箇所の数がわかります。

3. BrowserView の使用それぞれを移行する​

1. それぞれのインスタンス化を移行します。 WebContentsView と BrowserView のコンストラクターは本質的に同じ形状なので、これはかなり簡単なはずです。 どちらも webPreferences 引数を介して WebPreferences を受け入れます。

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

   info

   デフォルトでは、WebContentsView は白い背景でインスタンス化され、BrowserView は透明な背景でインスタンス化されます。 WebContentsView で透明な背景にするには、以下のように背景色をアルファ (不透明度) チャンネルが 00 の RGBA 16 進値に設定します。

   + 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 インスタンスメソッドをサイズ変更のリスナーへ移行します。

   - 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 の Issue トラッカーの WebContentsView タグを確認して、発生している問題が報告済かどうかご確認ください。 ここで Issue が見つからない場合は、お気軽に新しいバグレポートを追加してください。 テストケースの要点を含めてもらえると、Issue のより適切なトリアージに役立ちます！

おめでとうございます。WebContentsView への移行が完了しました！ 🎉

Electron チームは、Electron 33.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、Twitter や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更​

• PIN が必要な暗号化デバイスのロック解除に役立つハンドラ app.setClientCertRequestPasswordHandler(handler) を追加しました。 #41205
• 履歴管理を改善するために、2 つの新しい関数を追加して navigationHistory API を拡張しました。 #42014
• ネイティブのテーマの透明度チェックを改善しました。 #42862

累積的変更​

• Chromium 130.0.6723.44
  • Chrome 130 の新機能
  • Chrome 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 へとアップグレードしています。

新機能​

• PIN が必要な暗号化デバイスのロック解除に役立つハンドラ app.setClientCertRequestPasswordHandler(handler) を追加しました。 #41205
• V8 の致命的なエラーに関する診断レポートをサポートするために、ユーティリティプロセスにエラーのイベントを追加しました。 #43997
• ビューの境界線の半径をカスタマイズする View.setBorderRadius(radius) が追加されました。WebContentsView との互換性付きです。 #42320
• 履歴管理を改善するために、2 つの新しい関数を追加して navigationHistory API を拡張しました。 #42014

破壊的変更​

削除: macOS 10.15 のサポート​

macOS 10.15 (Catalina) は Chromium でサポートされなくなりました。

旧バージョンの Electron はこれらのオペレーティングシステムでも引き続き動作しますが、Electron v20.0.0 以降の動作には macOS 11 (High Sierra) 以降が必要です。

動作変更: ネイティブモジュールにC++20が必要になりました​

上流における変更により、V8 と Node.js の両方が、最小バージョンとしてC++20を必要とするようになりました。 ネイティブのNodeモジュールを使用する開発者は、 --std=c++17 ではなく --std=c++20 でモジュールをビルドする必要があります。 gcc9 以下のバージョンで作成されたイメージは、コンパイルするには gcc10 への更新が必要になる場合があります。 詳細は#43555を参照してください。

動作変更: WindowsにおけるカスタムプロトコルURLの処理​

Chromiumが「特別でないURL (Non-special URL)」をサポートのために変更を加えたため、Windowsファイルパスを使用するカスタムプロトコルURLは、非推奨となった protocol.registerFileProtocol と BrowserWindow.loadURL、WebContents.loadURL 、<webview>.loadURL の baseURLForDataURL プロパティでは正しく動作しなくなります。 protocol.handle もこれらのタイプのURLでは動作しませんが、これは元々そのように動作しているため、変更ではありません。

// 動作しない
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');

// 代替案
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 オプションによってイベントがトリガーされたとき null が返るようになります。

非推奨: BrowserWindowConstructorOption.type の textured オプション​

BrowserWindowConstructorOptions の type プロパティの textured オプションは非推奨となりました。代替となるオプションはありません。 このオプションはmacOSの NSWindowStyleMaskTexturedBackground スタイルマスクに依存していましたが、これは代替手段なく非推奨になりました。

非推奨: systemPreferences.accessibilityDisplayShouldReduceTransparency​

systemPreferences.accessibilityDisplayShouldReduceTransparency プロパティは非推奨となり、新しい nativeTheme.prefersReducedTransparency が推奨されます。新しいものでは全く同じ情報を提供しながら、クロスプラットフォームで動作します。

// 非推奨
const shouldReduceTransparency =
  systemPreferences.accessibilityDisplayShouldReduceTransparency;

// こちらで置き換えてください
const prefersReducedTransparency = nativeTheme.prefersReducedTransparency;

30.x.y サポートの終了​

プロジェクトの サポートポリシー に則り、Electron 30.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

こんにちは 👋、2024 年 Google Summer of Code (GSoC) の Electron のコントリビューターの、Peter です。

GSoC プログラムの過程で、Electron ドキュメントとその関数、クラスなどに API の履歴の機能を実装しました。これは、Node.js ドキュメント と同様の方法で、API ドキュメントの Markdown ファイルにシンプルかつ強力な YAML スキーマを使用できるようにし、Electron ドキュメントのウェブサイトでわかりやすく表示することで実現しました。

詳細​

API 履歴ドキュメント化システム / YAML スキーマ​

Markdown API ドキュメントにて、関数/クラスなどの履歴が HTML コメントで包まれた YAML コードブロックの形式で、その項目のヘッダーの直後に配置されるようになりました。

#### `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: "`trafficLightPosition` オプションが `customButtonOnHover` のウインドウで機能するようにしました。"
deprecated:
  - pr-url: https://github.com/electron/electron/pull/37094
    breaking-changes-header: deprecated-browserwindowsettrafficlightpositionposition
```
-->

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

信号機ボタンのカスタム位置を設定します。`titleBarStyle` が `hidden` に設定されている場合にのみ使用できます。

Node.js のドキュメントのように YAML を使用すると読みやすいので、これが最善のアプローチだと考えています。 この API 履歴は、できるだけ複雑にせず、簡単に書いたり読んだりできることが理想です。

上述の最終的なデザインは、実際に私が提案した以下のものとは大きく異なります。

<!--
```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: `trafficLightPosition` オプションが `customButtonOnHover` のウインドウで機能するようにしました。
```
-->

大きな変更としては、バージョン番号の削除です。

「[...] この提案について、私たちが指摘したい重要な変更点が 1 つあります。これは、提唱をレビューしていて議論されたときに浮上したものです。 [...]

[私たちは] 提唱のようなハードコードされたバージョン文字列ではなく、PR の URL (main への大本の PR) のみを使用するのが [最も欠点の少ない] アプローチであると判断しました。

これは、正確なバージョン番号を導き出すために使用できる唯一の真の情報源として機能し、変更が他のブランチにバックポートされた場合も mainでのドキュメントの変更は不要になります。」

— David Sanders (@dsanders11)、Slack にて

また、API が Electron から削除されるとドキュメントからも削除されるため、API 履歴には削除を含めないことにしました。

JavaScript 実装​

当初は、ドキュメントファイル内の API 履歴を抽出、検証/lint、変換するためのスクリプトを含んだ @electron/docs-api-history-tools npm パッケージを新しく作成する予定でした。

コーディング期間が始まる約 1 週間前に、メンターと話し合った結果、それはおそらく不要だと気づきました。

「皆さんこんにちは。話し合いの後でプロジェクトについて考えていました。依存関係のため、e/website と e/lint-roller では抽出ロジックを別々に対処する必要があることを考慮すると、API 履歴用の個別パッケージは不要かもしれません。」

提唱	改訂後

— Piotr Płaczek (私)、Slack にて

最終的に、私たちは私の当初のアイデアを実行しないことに決めました。

「@Piotr Płaczek それは良さそうですね！ いずれにしても、2 つの実装間で多くのコードを共有すべきだとわかれば、後のイテレーションで別のモジュールにリファクタリングできると思います 🙂」

— Erick Zhao (@erickzhao)、Slack にて

代わりに、私たちは、それらに最も関連性の高いさまざまなツールを Electron のリポジトリへと分割しました。

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

Electron のドキュメントのウェブサイトの UI とスタイル​

私は当初、API の履歴データを表示するためのシンプルな表を提案していました。

デザインプロトタイプ (閉じ状態)	デザインプロトタイプ (開き状態)

最終的に実装されたデザインは次のようになります。

これはプロトタイプとほぼ同じです。 最も重要な追加は、SemVer の範囲の使用です。これは、機能がどのバージョンに存在するかをより適切に伝えるために選びました (提案して頂いた Samuel Attard (@MarshallOfSound) さんに感謝します)。

これは、変更がサポートされている Electron のリリースライン全体に頻繁にバックポートされるため重要です。例えば、ある修正は Electron v32.0.0、v31.1.0、v30.2.0 に反映される可能性があります。 この場合、v31.0.0 には存在しないことになり、ユーザーは v30.x.x リリースに存在するという事実に基づいて誤って推測するかもしれないのです。

使用方法/スタイルガイド​

新機能の API 履歴ドキュメントの作成に特化した、使用方法/スタイルガイドを追加しました。 YAML スキーマの適切な使用方法を詳しく説明し、典型的/便利な例などを示しています。 こちら でご覧いただけます。

移行ガイド​

既存の API を新しいドキュメントシステムに移行する必要があるため、移行ガイドを作成しました。 これは、古い API を移行するときに開発者が実行する必要がある一般的な手順として、重大な変更の確認、過去のリリースの参照、古いコミットの確認などを取り上げています。 そして開発者に、使用方法/スタイル ガイドに従って既存のクラス/関数などの API に履歴のドキュメントを追加するように指示します。

残念ながら、これを効果的に自動化する方法は思いつきませんでした。 おそらくこれは AI/機械学習エンジニアにとっては楽しい仕事でしょうが、私にそのスキルはなく、誤って API 履歴に ハルシネーション を導入してしまうことが心配でした。 たとえ自動化されたとしても、その情報は最終的には人間によって検証される必要があるでしょう 😕。 このタスクは、おそらく Node.js ドキュメントの場合と同じように、ファイルごとに手動で実行する必要があります。

成果物​

• api-history.schema.json

  • API 履歴をドキュメント化するための包括的な YAML スキーマで、以下のサポートを含みます。
    • 機能追加
    • 非推奨
    • 変更
    • 関連プルリクエストへのリンク
    • バックポート
  • 提唱内容: electron/rfc#6
  • 実装/利用内容: electron/electron#42982
  • 利用内容: electron/website#594

• lint-markdown-api-history.ts

  • カスタムの YAML (技術的には JSON) スキーマに従って記述された YAML の API 履歴を lint するスクリプト。
    • 便利なエラーメッセージ
    • 包括的なドキュメント / コードのコメント
    • 広範囲にわたる Jest Vitest のテスト
    • 良好なパフォーマンス
  • 実装内容: electron/lint-roller#73
  • 利用内容: electron/electron#42982

• preprocess-api-history.ts

  • 誤った API 履歴がリポジトリに取り込まれた場合に備えて、簡単な検証を実行します。 また、Docusaurus が解析できないため、API 履歴ブロックを囲む HTML コメントタグも取り除きます。
  • 実装内容: electron/website#594

• transformers/api-history.ts

  • Markdown ドキュメントファイル内の YAML API 履歴ブロックを Markdown/HTML React の表 (ApiHistoryTable.tsx) に変換するスクリプト。
  • 実装内容: electron/website#594

• ApiHistoryTable.tsx

  • ドキュメントのウェブサイトで解析した API 履歴データの表示に使用する React の表のコンポーネント。
    • ウェブサイトの周りのデザインに従ったスタイルを使用します。
    • レスポンシブでアクセスしやすく、全体的に適切に記述された HTML、CSS、JS です。
  • 実装内容: electron/website#594

• styleguide.md

  • 新しい API 履歴ドキュメントシステムの使用方法/スタイルガイドのセクション。
    • わかりやすい
    • 十分な記述
    • サンプル付き
  • 実装/利用内容: electron/electron#42982

• api-history-migration-guide.md

  • 新しい API 履歴ドキュメントシステムの移行ガイド。
    • わかりやすい
    • 十分な記述
    • サンプル付き
  • 実装/利用内容: electron/electron#42982

おわりに​

この機能に取り組むのはとても楽しく、チームとのコードレビューやさまざまな実装の詳細の議論を通じて貴重な経験を積むことができました。

ドキュメントに API 履歴が追加されることで、Electron を使用する開発者、特に既存のアプリを数年前の Electron バージョンから移行しようとしている開発者の作業が、大幅に楽になると思います。

以下の私のメンターの方々にも心から謝意を述べたいと思います。

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

...そして、私の質問に回答してくださり、時間を割いてプルリクエストにフィードバックを提供して頂いた Electron チームの他のメンバーの方々にも感謝します。 大変お世話になりました。

Electron チームは、Electron 32.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、Twitter や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更​

• ドキュメントに新しく API バージョン履歴を追加しました。これは、Google Summer of Code の一環として @piotrpdev によって作成された機能です。 詳細については、こちらのブログ記事 をご覧ください。 #42982
• ウェブの File API から非標準の File.path 拡張を削除しました。 #42053
• ブロックされたパス内のファイルまたはディレクトリを開こうとしたときに、ウェブの ファイル システム API が失敗する流れを上流と整合させました。 #42993
• webcontents.navigationHistory に、次の既存のナビゲーション関連 API を追加しました: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear。 以前のナビゲーション API は非推奨になりました。 #41752

累積的変更​

• Chromium 128.0.6613.36
  • Chrome 128 の新機能
  • Chrome 127 の新機能
• Node 20.16.0
  • Node 20.16.0 ブログ記事
• V8 12.8

Electron 32 では、Chromium は 126.0.6478.36 から 128.0.6613.36 へ、Node は 20.14.0 から 20.16.0 へ、V8 は 12.6 から 12.8 へとアップグレードしています。

新機能​

• ユーティリティプロセスから開始された認証の要求に、app モジュールの 'login' イベントを介して応答するためのサポートが追加されました。 #43317
• CPUUsage 構造体に cumulativeCPUUsage プロパティを追加しました。このプロパティは、プロセスの起動以降に使用された CPU 時間の累計秒数を返します。 #41819
• webContents.navigationHistory に、次の既存のナビゲーション関連 API を追加しました: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear。 #41752
• WebContentsView を既存の webContents オブジェクトを受け入れるように拡張しました。 #42086
• nativeTheme に新しいプロパティ prefersReducedTransparency を追加しました。これは、ユーザーがシステムのアクセシビリティ設定を介して OS レベルの透過度を下げることを選択したかどうかを示します。 #43137
• ブロックされたパスでファイルまたはディレクトリを開こうとしたときに、ファイルシステムアクセス API が失敗する流れを上流と整合させました。 #42993
• Linux でウインドウコントロールオーバーレイ API を使えるようにしました。 #42681
• ネットワークリクエストで zstd 圧縮を使えるようにしました。 #43300

破壊的変更​

削除: File.path​

ウェブの File オブジェクトの非標準の path プロパティは、レンダラー内ですべてを実行するのが一般的だった時代に、ネイティブのファイルを操作する便利な方法として Electron の初期バージョンで追加されました。 ただし、これは標準からの逸脱であり軽微なセキュリティリスクも伴うため、Electron 32.0 以降では webUtils.getPathForFile メソッドに置き換えられました。

// 以前 (レンダラー)
const file = document.querySelector('input[type=file]');
alert(`Uploaded file path was: ${file.path}`);

// これから (レンダラー)
const file = document.querySelector('input[type=file]');
electron.showFilePath(file);

// これから (プリロード)
const { contextBridge, webUtils } = require('electron');

contextBridge.exposeInMainWorld('electron', {
  showFilePath(file) {
    // できればウェブコンテンツへの完全なファイルパスを
    // 公開しないことを推奨します。
    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 プロパティへ移動されました。

// 非推奨
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);

// こちらで置き換えてください
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);

動作変更: userDataのディレクトリ databases が削除される​

app.getPath('userData') が返すディレクトリに databases という名前のディレクトリがある場合、Electron 32 の初回実行で削除されます。 databases ディレクトリは WebSQL で使用されており、これは Electron 31 で削除されました。 Chromium はこのディレクトリを削除するクリーンアップを実行するようになりました。 Issue #45396 をご参照ください。

29.x.y サポートの終了​

プロジェクトの サポートポリシー に則り、Electron 29.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

Electron チームは、Electron 31.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、Twitter や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更​

• WebContentsView を既存の webContents オブジェクトを受け入れるように拡張しました。 #42319
• NODE_EXTRA_CA_CERTS のサポートを追加しました。 #41689
• window.flashFrame(bool) を macOS 上で持続的に点滅するように更新しました。 #41391
• WebSQL のサポートを削除しました #41868
• nativeImage.toDataURL が PNG 色空間を保つようにしました #41610
• webContents.setWindowOpenHandler が手動作成した BrowserWindow をサポートするように拡張しました。 #41432

累積的変更​

• Chromium 126.0.6478.36
  • Chrome 126 の新機能
  • Chrome 125 の新機能
• Node 20.14.0
  • Node 20.14.0 ブログ記事
• V8 12.6

Electron 31 では、Chromium は 124.0.6367.49 から 126.0.6478.36 へ、Node は 20.11.1 から 20.14.0 へ、V8 は 12.4 から 12.6 へとアップグレードしています。

新機能​

• Session に clearData メソッドを追加しました。 #40983
  • Session.clearData API に options パラメーターを追加しました。 #41355
• navigator.serial にサービスクラス ID によって要求される Bluetooth ポートのサポートを追加しました。 #41638
• Node の NODE_EXTRA_CA_CERTS 環境変数のサポートを追加しました。 #41689
• webContents.setWindowOpenHandler が手動作成した BrowserWindow をサポートするように拡張しました。 #41432
• ウェブ標準の ファイルシステム API のサポートを実装しました。 #41419
• WebContentsView を既存の WebContents インスタンスを受け入れるように拡張しました。 #42319
• webContents API に新しくインスタンスプロパティ navigationHistory と navigationHistory.getEntryAtIndex メソッドを追加しました。これによりアプリケーションがブラウズ履歴内の任意のナビゲーションエントリの URL とタイトルを取得できるようになります。 #41577 ^{(及び 29, 30)}

破壊的変更​

削除:WebSQL のサポート​

Chromium は WebSQL の上流サポートを削除し、Android のみに移行しました。 詳細は Chromium の削除する意図についての議論 をご参照ください。

動作変更: nativeImage.toDataURL が PNG 色空間を保つようにしました​

PNG デコーダの実装が色空間データを保持するように変更されました。 この関数から返される符号化されたデータは元と一致するようになります。

詳細は crbug.com/332584706 をご参照ください。

動作変更: win.flashFrame(bool) を macOS 上で持続的に点滅するようにしました​

これにより、Windows および Linux と同等の動作になります。 以前の動作: 最初の flashFrame(true) は Dock のアイコンを 1 回バウンスするだけ (NSInformationalRequest レベルを使用する場合) で、flashFrame(false) は何も行いません。 新しい動作: flashFrame(false) が呼び出されるまで、持続的に点滅します。 これは代わりに NSCriticalRequest レベルを使用しています。 NSInformationalRequest を明示的に使用してこれまで通り一度だけの Dock のアイコンをバウンスさせたい場合は、dock.bounce('informational') を使用できます。

28.x.y サポートの終了​

プロジェクトの サポートポリシー に則り、Electron 28.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

Electron チームは、Electron 30.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、Twitter や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更​

• ASAR 整合性の fuse が Windows でサポートされました (#40504)
  • 正しく設定されていない場合、ASAR 整合性が有効の既存のアプリは Windows 上で動作しない可能性があります。 Electron のパッケージ化ツールを使用しているアプリは、@electron/packager@18.3.1 または @electron/forge@7.4.0 にアップグレードしてください。
  • 詳細については私たちの ASAR 整合性のチュートリアル をご覧ください。
• WebContentsView と BaseWindow メインプロセスモジュールを追加しました。これは BrowserView を非推奨にして置き換えるものです (#35658)。 BrowserView から WebContentsView に移行する方法の詳細については、このブログ記事 をご覧ください。
  • BrowserView は WebContentsView の上のシムとなり、古い実装は削除されました。
  • 新しい WebContentsView API と他の類似 API との比較については、私たちの Web 埋め込みドキュメント をご参照ください。
• ファイルシステム API のサポートを実装しました (#41827)

累積的変更​

• Chromium 124.0.6367.49
  • Chrome 124 と デベロッパーツール 124 の新機能
  • Chrome 123 と デベロッパーツール 123 の新機能
• Node 20.11.1
  • Node 20.11.1 ノート
• V8 12.4

Electron 30 では、122.0.6261.39 から 124.0.6367.49 へ、Node は 20.9.2 から 20.11.1 へ、V8 は 12.2 から 12.4 へとアップグレードしています。

新機能​

• Webview に transparent のウェブ環境設定を追加しました。 (#40301)
• webContents API に新しくインスタンスプロパティ navigationHistory と navigationHistory.getEntryAtIndex メソッドを追加しました。これによりアプリケーションがブラウズ履歴内の任意のナビゲーションエントリの URL とタイトルを取得できるようになります。 (#41662)
• 新しく BrowserWindow.isOccluded() メソッドを追加しました。これによりアプリが覆い隠されている状態を確認できるようになります。 (#38982)
• ユーティリティプロセスから net モジュールを使用して行われたリクエストに対するプロキシ構成サポートを追加しました。 (#41417)
• navigator.serial にサービスクラス ID によって要求される Bluetooth ポートのサポートを追加しました。 (#41734)
• Node.js の NODE_EXTRA_CA_CERTS CLI フラグのサポートを追加しました。 (#41822)

破壊的変更​

動作変更: クロスオリジンの iframe が権限ポリシーを用いて機能にアクセスするようになりました​

クロスオリジンの iframe にアクセスするには、特定の iframe で利用可能な機能を allow 属性を介して指定しなければなりません。

詳細は ドキュメント をご参照ください。

削除: --disable-color-correct-rendering コマンドラインスイッチ​

このスイッチは正式にドキュメント化されたことはありませんが、削除したことをここに注記しておきます。 Chromium 自体が色空間のサポートを強化したため、このフラグは必要なくなります。

動作変更: macOS での BrowserView.setAutoResize の動作​

Electron 30 では、BrowserView は新しい WebContentsView API のラッパーになりました。

以前の BrowserView API の setAutoResize 関数は、macOS では autoresizing で、Windows と Linux ではカスタムアルゴリズムによって支えていました。 BrowserView をウインドウ全体に表示するなどの単純な使用例では、これら 2 つのアプローチの動作は同じでした。 ただしより高度なケースでは、Windows および Linux のカスタムサイズ変更アルゴリズムが macOS の自動サイズ変更 API の動作と完全に一致しませんでした。そのめ、BrowserView の自動サイズ変更は macOS 上では他のプラットフォームとは異なる動作でした。 この自動サイズ変更の動作がすべてのプラットフォーム間で標準化されました。

もしあなたのアプリが BrowserView をウィンドウ全体に表示するよりも複雑な操作を BrowserView.setAutoResize で行っていたのならば、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 にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。