メインコンテンツへ飛ぶ

Electron 33.0.0

· 読むのにかかる時間 1 分

Electron 33.0.0 がリリースされました! It includes upgrades to Chromium 130.0.6723.44, V8 13.0, and Node 20.18.0.


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

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

注目すべき変更

ハイライト

  • Added a handler, app.setClientCertRequestPasswordHandler(handler), to help unlock cryptographic devices when a PIN is needed. #41205
  • Extended navigationHistory API with 2 new functions for better history management. #42014
  • Improved native theme transparency checking. #42862

累積的変更

Electron 33 では、Chromium は 128.0.6613.36 から 130.0.6723.44 へ、Node は 20.16.0 から 20.18.0 へ、V8 は 12.8 から 13.0 へとアップグレードしています。

新機能

  • Added a handler, app.setClientCertRequestPasswordHandler(handler), to help unlock cryptographic devices when a PIN is needed. #41205
  • Added error event in utility process to support diagnostic reports on V8 fatal errors. #43997
  • Added View.setBorderRadius(radius) for customizing the border radius of views—with compatibility for WebContentsView. #42320
  • Extended navigationHistory API with 2 new functions for better history management. #42014

破壊的変更

Removed: macOS 10.15 support

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

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

Behavior Changed: Native modules now require C++20

Due to changes made upstream, both V8 and Node.js now require C++20 as a minimum version. Developers using native node modules should build their modiles with --std=c++20 rather than --std=c++17. Images using gcc9 or lower may need to update to gcc10 in order to compile. See #43555 for more details.

Behavior Changed: custom protocol URL handling on Windows

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

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

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

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

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

Behavior Changed: webContents property on login on app

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

Deprecated: textured option in BrowserWindowConstructorOption.type

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

Deprecated: systemPreferences.accessibilityDisplayShouldReduceTransparency

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

// Deprecated
const shouldReduceTransparency =
systemPreferences.accessibilityDisplayShouldReduceTransparency;

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

End of Support for 30.x.y

Electron 30.x.y has reached end-of-support as per the project's support policy. 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

E33 (2024 年 10 月)E34 (2025 年 1 月)E35 (Apr'25)
33.x.y34.x.y35.x.y
32.x.y33.x.y34.x.y
31.x.y32.x.y33.x.y

次回予告

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

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

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

API 履歴の導入 (GSoC 2024)

· 読むのにかかる時間 1 分

Electron API の履歴がドキュメント内で詳解されるようになります。


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

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

Electron 32.0.0

· 読むのにかかる時間 1 分

Electron 32.0.0 がリリースされました! これには Chromium 128.0.6613.36、V8 12.8、Node 20.16.0 へのアップグレードが含まれています。


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

何かフィードバックがあれば、TwitterMastodon で共有したり、コミュニティの 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

累積的変更

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

非推奨: WebContentsclearHistory, canGoBack, goBack, canGoForward, goForward, goToIndex, canGoToOffset, goToOffset

WebContents インスタンスのナビゲーション関連の API が非推奨になりました。 これらの API は、ナビゲーション履歴を管理するための、より構造化された直感的なインターフェースを提供するために、WebContentsnavigationHistory プロパティへ移動されました。

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

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

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

E32 (2024 年 8 月)E33 (2024 年 10 月)E34 (2025 年 1 月)
32.x.y33.x.y34.x.y
31.x.y32.x.y33.x.y
30.x.y31.x.y32.x.y

次回予告

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

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

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

Electron 31.0.0

· 読むのにかかる時間 1 分

Electron 31.0.0 がリリースされました! これには Chromium 126.0.6478.36、V8 12.6、Node 20.14.0 へのアップグレードが含まれています。


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

何かフィードバックがあれば、TwitterMastodon で共有したり、コミュニティの 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

累積的変更

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

新機能

  • SessionclearData メソッドを追加しました。 #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 に新しくインスタンスプロパティ navigationHistorynavigationHistory.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 にアップグレードすることを推奨します。

E31 (2024 年 6 月)E32 (2024 年 8 月)E33 (2024 年 10 月)
31.x.y32.x.y33.x.y
30.x.y31.x.y32.x.y
28.x.y29.x.y31.x.y

次回予告

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

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

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

Electron 30.0.0

· 読むのにかかる時間 1 分

Electron 30.0.0 がリリースされました! これには Chromium 124.0.6367.49、V8 12.4、Node.js 20.11.1 へのアップグレードが含まれています。


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

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

注目すべき変更

ハイライト

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

累積的変更

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 に新しくインスタンスプロパティ navigationHistorynavigationHistory.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 からは自動サイズ変更の動作が一貫しているため、そのロジックは必要なくなります。

削除: WebContentscontext-menu にある params.inputFormType プロパティ

WebContentscontext-menu イベント内の params オブジェクトにある inputFormType プロパティを削除しました。 代わりに新しい formControlType プロパティを使用してください。

削除: process.getIOCounters()

Chromium はこの情報へのアクセスを削除しました。

27.x.y サポートの終了

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

E30 (Apr'24)E31 (2024 年 6 月)E32 (2024 年 8 月)
30.x.y31.x.y32.x.y
29.x.y30.x.y31.x.y
28.x.y29.x.y30.x.y

次回予告

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

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

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

Google Summer of Code 2024

· 読むのにかかる時間 1 分

Electron が第 20 回 Google Summer of Code (GSoC) 2024 のメンター組織として承認されたことをお知らせします! Google Summer of Code は、オープンソースソフトウェア開発に新たな貢献者を呼び込むことに重点を置いた国際プログラムです。

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

私たちについて

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

Electron のコア以外にも以下のように、Electron 組織の維持に役立つ様々なプロジェクトに取り組んでいます。

Summer of Code の貢献者の方は、github.com/electron 傘下の多くのプロジェクトのうちの 1 つで、Electron のコアの貢献者の一部と協力して頂きます。

応募する前に

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

Electron アプリの頒布形式の詳細について学ぶには、サンプルアプリケーションを作成して Electron Forge を試すのもよいでしょう。

npm init electron-app@latest my-app

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

info

Google Summer of Code に初めて参加する方やオープンソース全般に馴染みがない方は、コミュニティに参加する前に、まず Google の 貢献者ガイド を読むことをお勧めします。

計画書の執筆

Electron との共同開発に興味を持てましたか? まずは、私たちが用意した 7 つのプロジェクトアイデア案 をご覧ください。 掲載されているアイデアは、すべて企画のために現在公開中のものです。

この他に検討して欲しいアイデアをお持ちですか? 提案プロジェクトのリストにない新しいアイデアも歓迎しますが、アプローチを十分に概説し、かつ詳細に説明するようにしてください。 あまり自信がないのであれば、リストのアイデアに従うことをお勧めします。

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

  • 計画書: この夏のプログラムの間に達成する目標の計画を詳細に記した文書。
  • 開発者としての経歴。 履歴書がある場合は、コピーを添付してください。 なければ、過去の技術経験についてお教えください。
    • 特定の分野での経験不足で不合格となることはありませんが、私たちメンターがあなたを最大限にサポートし、あなたの夏のプロジェクトが成功するよう計画を立てるのに役立ちます。

Electron の応募で提出する一式の詳細なガイドはこちらです。 計画書は Google Summer of Code ポータルに直接提出してください。 注意として、申請ポータルから送信せずに Electron チームへ電子メールで送信した計画書は、最終提出物とみなされません。

計画書についてさらに詳しいガイダンスが必要な場合や、何を書き込めばよいかわからない場合は、Google Summer of Code 公式の計画書作成アドバイス に従うこともお勧めします。

応募開始は 2024 年 3 月 18 日、締め切りは 2024 年 4 月 2 日 です。

info

2022 年の Google Summer of Code では、インターンの @aryanshridhar さんには素晴らしい働きをして頂きました。 Aryan さんが夏に Electron で取り組んだことを確認したい方は、2022 GSoC プログラムのアーカイブ から彼のレポートを閲覧できます。

質問?

ブログ記事で取り上げられていない質問や計画書の執筆に関するお問い合わせは、summer-of-code@electronjs.org までメールしていただくか、GSoC FAQ をご確認ください。

リソース

Electron 29.0.0

· 読むのにかかる時間 1 分

Electron 29.0.0 がリリースされました! これには Chromium 102.0.6261.39、V8 12.2、Node.js 20.9.2 へのアップグレードが含まれています。


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

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

注目すべき変更

ハイライト

  • 新しいトップレベルの webUtils モジュールを追加しました。これは Web API のオブジェクトと対話するユーティリティレイヤーを提供するレンダラープロセスのモジュールです。 このモジュールで最初に利用可能な API は webUtils.getPathForFile です。 Electron の以前の File.path 拡張は Web 標準から逸脱していましたが、この新しい API は現在の Web 標準の動作に沿ったものになっています。

累積的変更

Electron 29 では、120.0.6099.56 から 122.0.6261.39 へ、Node は 18.18.2 から 20.9.0 へ、V8 は 12.0 から 12.2 へとアップグレードしています。

新機能

  • Web API のオブジェクトと対話するユーティリティレイヤーとして webUtils モジュールを追加しました。これは File.path 拡張を置き換えるものです。 #38776
  • ユーティリティプロセスnet モジュールを追加しました。 #40890
  • 新しい Electron FusegrantFileProtocolExtraPrivileges を追加しました。これは、file:// プロトコルを Chromium と一致するよりセキュアな動作に制限するものです。 #40372
  • カスタムスキームで V8 コードのキャッシュを許可するためのオプションを protocol.registerSchemesAsPrivileged に追加しました。 #40544
  • app.{set|get}LoginItemSettings(settings) を macOS 13.0 以降で Apple 推奨の新しい基盤フレームワークを使用するように移行しました。 #37244

破壊的変更

動作変更:ipcRenderercontextBridge を越えて送信できなくなりました。

ipcRenderer モジュール全体をオブジェクトとして contextBridge 経由で送信しようとすると、ブリッジの受信側には空のオブジェクトが生成されるようになりました。 この変更は、セキュリティの落とし穴を撤去/軽減するために行われました。 ipcRenderer やそのメソッドをブリッジ越しに直接公開してはいけません。 代わりに、以下のような安全なラッパーを用意してください。

contextBridge.exposeInMainWorld('app', {
onEvent: (cb) => ipcRenderer.on('foo', (e, ...args) => cb(args)),
});

削除: apprenderer-process-crashed イベント

app での renderer-process-crashed イベントは削除されました。 代わりに新しいイベントである render-process-gone を使用してください。

// 削除済み
app.on('renderer-process-crashed', (event, webContents, killed) => {
/* ... */
});

// こちらで置き換えてください
app.on('render-process-gone', (event, webContents, details) => {
/* ... */
});

削除: WebContents<webview> crashed イベント

WebContents<webview>crashed イベントは削除されました。 代わりに新しいイベントである render-process-gone を使用してください。

// 削除済み
win.webContents.on('crashed', (event, killed) => {
/* ... */
});
webview.addEventListener('crashed', (event) => {
/* ... */
});

// こちらに置き換えてください
win.webContents.on('render-process-gone', (event, details) => {
/* ... */
});
webview.addEventListener('render-process-gone', (event) => {
/* ... */
});

削除: appgpu-process-crashed イベント

appgpu-process-crashed イベントは削除されました。 代わりに新しいイベントである child-process-gone を使用してください。

// 削除済み
app.on('gpu-process-crashed', (event, killed) => {
/* ... */
});

// こちらに置き換えてください
app.on('child-process-gone', (event, details) => {
/* ... */
});

26.x.y サポートの終了

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

E29 (Feb'24)E30 (Apr'24)E31 (2024 年 6 月)
29.x.y30.x.y31.x.y
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y

次回予告

この度 Electron がコミュニティの Request for Comments (RFC) のプロセスを追加したことはご存知でしょうか? フレームワークに機能を追加したい場合、RFC はその設計においてメンテナとの対話を始める有用なツールとなります。 プルリクエストで議論されている今後の変更も確認できます。 詳細については、electron/rfcs の紹介 のブログ記事をご覧いただくか、electron/rfcs リポジトリの README を直接ご確認ください。

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

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

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

electron/rfcs の紹介

· 読むのにかかる時間 1 分

Electron の API ワーキング グループ は、Electron のコアへのより大きな変更を支援するために、オープンな Requests for Comments (RFC) プロセスを採用しようとしています。

なぜ RFC なのでしょうか?

要するに、Electron のコアへの重要な変更を実装するプロセスをスムーズにしたいのです。

現在、新しいコードの変更は主に GitHub の Issue とプルリクエストを通じて議論されています。 Electron のほとんどの変更においては、これは良いシステムです。 多くのバグ修正、ドキュメントの変更、さらには新機能も、標準の GitHub フローを介せば非同期的にレビューおよびマージできるほど簡単です。

より重大な変更—たとえば大規模な API サーフェスや、Electron アプリの大部分に影響する重大な変更などの場合、コードの大部分が記述される前のアイデア段階でレビューを行うほうが合理的です。

このプロセスは一般公開されるように設計すべきです。そうすることで、Electron に導入される前に、オープンソースコミュニティ全体が潜在的な変更についてフィードバックを提供しやすくなります。

どのように動作するのですか?

RFC 全体のプロセスは、GitHub 上の electron/rfcs リポジトリに保管されます。 プロセスの手順は、リポジトリの README で詳しく説明しています。

簡単に言うと、electron/rfcs リポジトリに PR が作成されると、RFC は 提唱 になります。 提唱の RFC は次のように遷移します。

  • アクティブ は、PR がリポジトリの main ブランチにマージされた場合になります。つまり、Electron のメンテナが electron/electron での実装に同意できることを意味します。
  • 拒絶 は PR が最終的に拒否された場合になります。
info

RFC が アクティブ になるには、PR が少なくとも 2 人の API ワーキンググループのメンバーによって承認されなければなりません。 マージ前に、RFC は WG メンバーの 3 分の 2 以上の定足数によって開かれた会議で同期的に提示され、全会一致で承認される必要があります。 合意に達した場合、1 か月の最終コメント期間が開始され、その後 PR がマージされます。

実装が electron/electron にマージされたとき、アクティブな RFC は 完了 になります。

誰が参加できますか?

Electron コミュニティの誰もが、RFC を提出したり、electron/rfcs リポジトリにフィードバックを残したりできます!

私たちは、このプロセスを双方向の対話にして、コミュニティの参加を奨励し、将来これらの API を使用する可能性のある Electron アプリからの多様な意見を得たいと考えていました。 現在提唱状態の RFC にフィードバックを残したい方向けに、Electron のメンテナが既に作成したいくつかの RFC を下記します。

クレジット

Electron の RFC プロセスは、多くの確立されたオープンソースの RFC プロセスに基づいてモデル化されました。 多くのアイデアやコピーライティングの主要部分のインスピレーションは、以下から得ました。

"runAsNode" の CVE に関する声明

· 読むのにかかる時間 1 分

今日このごろ、いくつかの有名な Electron アプリに対して最近提出された公開 CVE について Electron チームが警告を受けました。 CVE は、Electron の 2 つの fuse - runAsNodeenableNodeCliInspectArguments - に関連しており、これらのコンポーネントを積極的に無効化しない場合、遠隔攻撃者がこれらのコンポーネントを介して任意のコードを実行できると誤って主張しています。

これらの CVE が誠意を持って提出されたとは考えていません。 まず、この記述は誤りです - この構成では遠隔コード実行は 不可能です。 第二に、これらの CVE で指摘されている企業は、バグ報奨金プログラムを実施しているにもかかわらず、そのバグを通知されていません。 最後に、問題のコンポーネントを無効にするとアプリのセキュリティが強化されることは信じられますが、その CVE が適切な重大度で登録されているとは考えられません。 「Critical」は最も危険な問題に対して予約されたものですが、今回の場合は明らかに当てはまりません。

CVE は誰でも発行できます。 これはソフトウェア業界全体の健全性にとっては良いことですが、一人のセキュリティ研究者が評判を高めるために「CVE を稼ぐ」ことは役立ちません。

とはいえ、恐ろしい「重大」な深刻度を持つ CVE が存在するだけでエンドユーザーの混乱を招く可能性があることは理解しています。そのためプロジェクトとして、問題に対処するためのガイダンスと支援を提供したいと考えています。

どのような影響がありますか?

CVE をレビューしたところ、Electron チームはこれらの CVE は重大でないと判断しました。

この攻撃者は、ハードウェアに物理的にアクセスするか、完全な遠隔コード実行を実現することによって、マシン上で任意のコマンドを実行できる必要があります。 これは繰り返しとなっています。ここで説明されている脆弱性を利用するには、攻撃者が対象のシステムに既にアクセスできていなければなりません

例えば、Chrome は 脅威モデルで物理的にローカルな攻撃を考慮していません

これらの攻撃は Chrome の脅威モデルの範囲外であると考えています。これは、ユーザとしてデバイスにログインした悪意のあるユーザーや、オペレーティングシステムのユーザアカウントの権限でソフトウェアを実行できる悪意のあるユーザーから Chrome (または任意のアプリケーション) を保護する方法がないためです。 このような攻撃者は、実行可能ファイルや DLL を変更したり、PATH などの環境変数を変更したり、構成ファイルを変更したり、ユーザアカウントが所有するデータを読み取ったり、それを攻撃者自身に電子メールで送信したりできます。 このような攻撃者はデバイスを完全に制御できるため、Chrome が施せる対策では防御を完全に保証できません。 この問題は Chrome に特有のものではありません — すべてのアプリケーションは物理的にローカルなユーザを信頼せざるをえません。

CVE に記載されているエクスプロイトにより攻撃者は、影響を受けるようなアプリを、継承された TCC (透明性、同意、制御) の権限を持つ汎用 Node.js プロセスとして使用できるようになります。 したがって、たとえばアプリにアドレス帳へのアクセスが許可されている場合、攻撃者はそのアドレス帳へのアクセスを継承するアプリを Node.js として実行し、任意のコードを実行できます。 これは一般に「Living Off The Land」攻撃として知られています。 攻撃者は通常、PowerShell や Bash などのツールを用いて任意コード実行をします。

影響はありますか?

デフォルトでは、リリースされている全バージョンの Electron は runAsNodeenableNodeCliInspectArguments の機能が有効です。 Electron Fuses のドキュメント で説明されているように、これらをオフにしていない場合、アプリが「Living Off the Land」攻撃に利用される危険性は同様に高くなります。 繰り返し強調しますが、攻撃者は 既に 被害者のマシン上でコードとプログラムを実行できている必要があります。

緩和策

この問題を軽減する最も簡単な方法は、あなたの Electron アプリの runAsNode の Fuse を無効化することです。 runAsNode ヒューズは、ELECTRON_RUN_AS_NODE 環境変数が尊重されるかどうかを切り替えます。 これらのヒューズを切り替える方法については、Electron Fuses のドキュメント をご参照ください。

注意としてこの Fuse が無効になっている場合、メインプロセスの process.fork はこの環境変数に依存して動作するため、期待通りに動作しなくなることがあります。 代わりに、ユーティリティプロセス を使用することを推奨します。これは、スタンドアロンの Node.js プロセス (SQLite サーバーのプロセスや同様の場合) が必要な多くのユースケースで機能します。

Electron アプリで推奨されるセキュリティのベストプラクティスの詳細については、セキュリティチェックリスト をご覧ください。

Electron 28.0.0

· 読むのにかかる時間 1 分

Electron 28.0.0 がリリースされました! これには Chromium 120.0.6099.56、V8 12.0、Node.js 18.18.2 へのアップグレードが含まれています。


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

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

注目すべき変更

ハイライト

  • ECMAScript モジュール、略して ESM のサポートを実装しました (ECMAScript モジュールとは何かですって? こちらで詳しく学べます。 これは Electron での ESM サポートだけでなく、UtilityProcess API のエントリポイントなどの領域も含まれます。 詳細については 私たちの ESM の ドキュメント をご参照ください。
  • 加えて Electron Forge は、Electron 自体での ESM サポートだけでなく Electron アプリケーションのパッケージ化、ビルド、開発においても ESM をサポートしています。 このサポートは Forge v7.0.0 以降となります。

累積的変更

新機能

  • ESM サポートを有効化しました。 #37535
  • UtilityProcess API に ESM エントリポイントを追加しました。 #40047
  • display オブジェクトに、detectedmaximumCursorSizenativeOrigin を含むいくつかのプロパティを追加しました。 #40554
  • Linux で ELECTRON_OZONE_PLATFORM_HINT 環境変数のサポートを追加しました。 #39792

破壊的変更

動作変更:WebContents.backgroundThrottling を false にすると、ホストの WebContents 内のすべての BrowserWindow に影響します

WebContents.backgroundThrottling を false に設定すると、BrowserWindow によって表示されるすべての WebContents でのフレーム抑制が無効になります。

削除: BrowserWindow.setTrafficLightPosition(position)

BrowserWindow.setTrafficLightPosition(position) は削除されたので、代わりに BrowserWindow.setWindowButtonPosition(position) API を使用してください。こちらは、デフォルトの位置へリセットする際に { x: 0, y: 0 } ではなく null を受け取るようになっています。

// Electron 28 で非推奨
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// こちらに置き換えてください
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

削除: BrowserWindow.getTrafficLightPosition()

BrowserWindow.getTrafficLightPosition() は削除されたので、代わりに BrowserWindow.getWindowButtonPosition() API を使用してください。こちらは、カスタム位置が無ければ { x: 0, y: 0 } ではなく null を返すようになっています。

// Electron 28 で削除
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
// カスタム位置が無い時。
}

// こちらに置き換えてください
const ret = win.getWindowButtonPosition();
if (ret === null) {
// カスタム位置が無い時。
}

削除: ipcRenderer.sendTo()

ipcRenderer.sendTo() API は削除されました。 これはレンダラー間で MessageChannel を設置するように置き換える必要があります。

IpcRendererEventsenderIdsenderIsMainFrame のプロパティも削除されました。

削除: app.runningUnderRosettaTranslation

app.runningUnderRosettaTranslation プロパティは削除されました。 代わりに app.runningUnderARM64Translation を使用してください。

// 削除されました
console.log(app.runningUnderRosettaTranslation);
// こちらで置き換えてください
console.log(app.runningUnderARM64Translation);

25.x.y サポートの終了

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

E28 (Dec'23)E29 (Feb'24)E30 (Apr'24)
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y
26.x.y27.x.y28.x.y

次回予告

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

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

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