メインコンテンツへ飛ぶ

Migrating from BrowserView to WebContentsView

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

BrowserView has been deprecated since Electron 30 and is replaced by WebContentView. Thankfully, migrating is fairly painless.


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

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

Migration steps

1. Upgrade Electron to 30.0.0 or higher

警告

Electron releases may contain breaking changes that affect your application. It’s a good idea to test and land the Electron upgrade on your app first before proceeding with the rest of this migration. A list of breaking changes for each Electron major version can be found here as well as in the release notes for each major version on the Electron Blog.

2. Familiarize yourself with where your application uses BrowserViews

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

ヒント

For the most part, each instance where your app instantiates new BrowserViews can be migrated in isolation from the others.

3. Migrate each usage of BrowserView

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

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

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

    + this.webContentsView.setBackgroundColor("#00000000");
  2. Migrate where the BrowserView gets added to its parent window.

    - this.browserWindow.addBrowserView(this.tabBar)
    + this.browserWindow.contentView.addChildView(this.tabBar);
  3. Migrate BrowserView instance method calls on the parent window.

    Old MethodNew Methodノート
    win.setBrowserViewwin.contentView.removeChildView + win.contentView.addChildView
    win.getBrowserViewwin.contentView.children
    win.removeBrowserViewwin.contentView.removeChildView
    win.setTopBrowserViewwin.contentView.addChildViewCalling addChildView on an existing view reorders it to the top.
    win.getBrowserViewswin.contentView.children
  4. Migrate the setAutoResize instance method to a resize listener.

    - this.browserView.setAutoResize({
    - vertical: true,
    - })

    + this.browserWindow.on('resize', () => {
    + if (!this.browserWindow || !this.webContentsView) {
    + return;
    + }
    + const bounds = this.browserWindow.getBounds();
    + this.webContentsView.setBounds({
    + x: 0,
    + y: 0,
    + width: bounds.width,
    + height: bounds.height,
    + });
    + });
    ヒント

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

4) Test and commit your changes

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

Congrats, you’ve migrated onto WebContentsViews! 🎉

Electron 33.0.0

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

Electron 33.0.0 がリリースされました! これには Chromium 130.0.6723.44、V8 13.0、Node 20.18.0 へのアップグレードが含まれています。


Electron チームは、Electron 33.0.0 のリリース発表にワクワクしています! You can install it with npm via npm install electron@latest or download it from our releases website. このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、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

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 のリリース発表にワクワクしています! You can install it with npm via npm install electron@latest or download it from our releases website. このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、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 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 のリリース発表にワクワクしています! You can install it with npm via npm install electron@latest or download it from our releases website. このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、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 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 のリリース発表にワクワクしています! You can install it with npm via npm install electron@latest or download it from our releases website. このリリースの詳細は続きをご覧ください。

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

注目すべき変更

  • ASAR 整合性の fuse が Windows でサポートされました (#40504)
    • 正しく設定されていない場合、ASAR 整合性が有効の既存のアプリは Windows 上で動作しない可能性があります。 Electron のパッケージ化ツールを使用しているアプリは、@electron/packager@18.3.1 または @electron/forge@7.4.0 にアップグレードしてください。
    • 詳細については私たちの ASAR 整合性のチュートリアル をご覧ください。
  • Added WebContentsView and BaseWindow main process modules, deprecating & replacing BrowserView (#35658). Learn more about how to migrate from BrowserView to WebContentsView in this blog post.
    • BrowserViewWebContentsView の上のシムとなり、古い実装は削除されました。
    • 新しい WebContentsView API と他の類似 API との比較については、私たちの Web 埋め込みドキュメント をご参照ください。
  • ファイルシステム API のサポートを実装しました (#41827)

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 のリリース発表にワクワクしています! You can install it with npm via npm install electron@latest or download it from our releases website. このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、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 アプリで推奨されるセキュリティのベストプラクティスの詳細については、セキュリティチェックリスト をご覧ください。