跳转到主内容

Electron 29.0.0

· 阅读时间:约 5 分钟

Electron 29.0.0 已发布! 它包括升级 Chromium 122.0.6261.39,和 V8 12.2 以及 Node.js 20.9.2。


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

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

重要变化​

重点内容​

  • 添加了一个新的顶级 webUtils 模块,这是一个渲染进程模块,提供与 Web API 对象交互的实用程序层。 模块中第一个可用的 API 是 webUtils.getPathForFile。 Electron 以前的 File.path 扩充偏离了网页标准;这个新的 API 更符合当前的 web 标准行为。

架构(Stack)更新​

Electron 29 将 Chromium 从 120.0.6099.56 升级到 122..0.661.39, Node 从 18.18.2 升级到 20.9.0,V8 从 12.0 升级到 12.2。

新特性​

  • 添加了新的 webUtils 模块,一个与 Web API 对象交互的实用程序层,替换 File.path 扩充。 #38776
  • 添加 net 模块到 utility process。 #40890
  • 添加了一个新的 Electron Fuse, grantFileProtocolExtravileges 让 file:// 协议使其具有更安全和更严格的行为,与 Chromium 相匹配。 #40372
  • 在 protocol.registerSchemesAsseged 中添加了一个选项,以允许自定义协议开启 V8 code cache。 #40544
  • 迁移 app.{set|get}LoginItemSettings(settings) 以便在 MacOS 13.0+ 上使用 Apple 推荐的新底层框架。 #37244

重大更改​

行为改变:ipcRenderer 不能再通过 contextBridge 发送​

现在通过 contextBridge 传送整个 ipcRenderer 模块作为对象,会在 bridge 的接收方收到一个 空对象。 此更改是为了消除/减轻一种安全隐患。 你不应该直接暴露 bridge 上的 ipcRenderer 或它的方法。 相反,应该提供一个像下面这样的安全包装器:

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

移除:app 上的 render-process-crashed 事件​

The renderer-process-crashed event on app has been removed. 改用新的 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) => {
/* ... */
});

Removed: gpu-process-crashed event on app​

app 上的 gpu-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(24 年 2 月)E30(24 年 4 月)E31 (24 年 6 月)
29.x.y30.x.y31.x.y
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y

接下来​

您是否知道 Electron 最近添加了社区征求意见 (RFC) 流程? 如果您想在框架中添加一项功能,RFC 可以成为您与维护者就功能设计展开对话的有用工具。 您还可以查看 PR 中正在讨论的即将发生的更改。 若要了解更多信息,请直接查看我们的 introduction electron/rfcs 博客文章,或查看 electron/rfcs 版本库的 README。

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

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

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

介绍 electron/rfcs

· 阅读时间:约 4 分钟

Electron 的 API 工作组 正在采用开放的 征求意见 (RFC) 流程来帮助引导更大的变更 到 Electron core。

为什么要使用 RFC?​

简而言之,我们希望顺利完成 Electron core 重大变更的落地过程。

目前,新的代码主要通过 GitHub 上的 issues 和拉取代码合并请求进行变更的。 对于 Electron 的大多数更改,这是一个很好的体系。 许多错误修复、文档更改、 甚至新功能也足够简单,可以通过以下方式异步审查和合并 标准 GitHub 流程。

对于更重大的变化-例如,大型 API 或会影响大多数 Electron 应用程序的破坏性更改,在 构思阶段进行审查是有意义的。

这个过程旨在对公众开放,这也将使得广大 开源社区能够在这些变化落实到 Electron之前,更容易地提供反馈。

它是如何工作的?​

整个 RFC(请求评论)过程托管在 GitHub 上的 electron/rfcs 仓库中。 步骤在仓库的 README 中有详细描述。

简而言之,一旦向 electron/rfcs 仓库提交了 PR,一个 RFC 就被提出了。 一个被提出的 RFC 会变成:

  • Active,当 PR 被合并到仓库的 main 分支时,这意味着 Electron 的维护者对在 electron/electron 中实施该提案持开放态度,或者
  • Declined,如果 PR 最终被拒绝。
info

要使 RFC 变为 Active 状态,PR 必须至少获得 2 名 API 工作组成员的批准。 在合并之前,RFC 应该同步地被呈现,并且至少有三分之二的工作组(WG)成员一致同意才能被接受。 如果达成共识,将触发为期一个月的最终评论期,之后将合并 PR。

如果实施已经合并到 electron/electron 中,一个激活的 RFC 就被视为 Completed。

谁可以参与?​

Electron 社区中的任何人都可以提交 RFC 或在 electron/rfcs 仓库上留下反馈!

我们希望将这个过程变成一种双向对话,并鼓励社区参与,以便从可能在未来使用这些 API 的 Electron 应用程序中获得多样化的意见。 如果你 对当前提出的 RFC 留下反馈感兴趣,Electron 的维护者们已经创建了 一些:

致谢​

Electron 的 RFC 流程借鉴了许多已建立的开源 RFC 流程。 许多想法和主要文案的灵感来源于:

关于 "runAsNode" CVEs 的声明

· 阅读时间:约 6 分钟

今天早些时候,Electron 团队被告知,最近有几个公开的 CVEs 针对几个著名的 Electron 应用程序进行了提交。 这些 CVE 与 Electron 的两个 fuses(保险丝) - runAsNode 和 enableNodeCliInspectArguments - 相关,并错误地声称,如果这些组件没有被积极禁用,远程攻击者能够通过这些组件执行任意代码。

我们认为这些 CVE 并非出于善意提交。 首先,这个声明是不正确的 - 配置并不允许远程代码执行。 其次,尽管拥有漏洞赏金计划,但在这些 CVE 中被点名的公司并没有收到通知。 最后,虽然我们确实相信禁用相关组件可以增强应用程序的安全性,但我们认为这些 CVE 的提交并没有准确反映其严重性。 “Critical”级别是为最高危险的问题保留的,显然这里的情况并非如此。

任何人都可以申请 CVE。 虽然这对软件行业的整体健康有益,但“挖掘 CVEs”来增强单个安全研究员的声誉并没有帮助。

话虽如此,我们理解仅仅是一个带有可怕的 critical 严重性的 CVE 的存在可能会导致用户感到困惑,因此作为一个项目,我们希望提供指导和协助来处理这个问题。

这会给我带来什么影响?​

在审查了 CVEs 之后,Electron 团队认为这些 CVEs 并不是 critical 的。

攻击者需要已经能够在机器上执行任意命令,无论是通过对硬件的物理访问还是通过实现完全的远程代码执行。 这值得重申:所描述的漏洞_要求攻击者已经能够访问被攻击的系统_。

例如,Chrome 在其威胁模型中不考虑本地物理攻击:

我们认为这些攻击超出了 Chrome 的威胁模型范围,因为对于已经能够以你的身份登录你的设备或者能够以你的操作系统用户账户的权限运行软件的恶意用户,Chrome(或任何应用程序)无法进行防御。 这样的攻击者可以修改可执行文件和DLL文件,更改像 PATH 这样的环境变量,更改配置文件,读取你的用户账户所拥有的任何数据,将其通过电子邮件发送给自己等等。 这样的攻击者对你的设备拥有完全的控制权,Chrome 所能做的任何事情都无法提供严格的防御保证。 这个问题不仅仅存在于Chrome - 所有应用程序都必须信任本地物理用户。

利用 CVE 中描述的漏洞,攻击者可以将受影响的应用程序用作具有继承 TCC 权限的通用 Node.js 进程。 因此,如果应用程序例如已被授权访问地址簿,攻击者可以将应用程序作为 Node.js 运行,并执行将继承该地址簿访问权限的任意代码。 这通常被称为“寄生式攻击”。 攻击者通常使用 PowerShell、Bash 或类似工具来运行任意代码。

我是否受到了影响?​

默认情况下,所有发布版本的 Electron 都启用了 runAsNode 和 enableNodeCliInspectArguments 功能。 如果您没有按照 Electron Fuses 文档中描述的方法关闭它们,那么您的应用程序同样容易受到“寄生式攻击”的影响。 再次强调,攻击者需要已经能够在受害者的机器上执行代码和程序。

缓解措施​

减轻这个问题的最简单方法是在您的 Electron 应用程序中禁用 runAsNode fuse。 runAsNode fuse 用于切换是否考虑 ELECTRON_RUN_AS_NODE ` 环境变量。 请参阅 Electron Fuses 文档以获取有关如何切换这些 fuses 的信息。

请注意,如果禁用了这个 fuse,那么主进程中的 process.fork 将无法按预期运行,因为它依赖于这个环境变量来运行。 相反,我们建议您使用实用进程,它适用于许多需要独立的 Node.js 进程的用例(例如 Sqlite 服务器进程或类似情况)。

您可以在我们的安全清单中找到更多关于我们推荐的 Electron 应用程序的安全最佳实践的信息。

Electron 28.0.0

· 阅读时间:约 5 分钟

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 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

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

重要变化​

重点内容​

  • 实现了对 ECMAScript 模块或 ESM 的支持(什么是 ECMAScript 模块?) 在这里了解更多信息. 这包括在 Electron 本身中支持 ESM,以及诸如 UtilityProcess API 入口点等方面。 详情见我们的 ESM 文档 以获取更多详细信息。
  • 除了在 Electron 本身中启用 ESM 支持外,Electron Forge 还支持使用 ESM 来打包、构建和开发 Electron 应用程序。 您可以在 Forge v7.0.0 或更高版本中找到这种支持。

架构(Stack)更新​

新特性​

  • 启用 ESM 支持。 #37535
  • 为 UtilityProcess API 添加了 ESM 入口点。 #40047
  • 添加了几个属性到 display 对象中,包括 detected,maximumCursorSize 和 nativeOrigin。 #40554
  • 新增对 Linux 上 ELECTRON_OZONE_PLATFORM_HINT 环境变量的支持。 #39792

重大更改​

行为改变:在宿主 BrowserWindow 中将 WebContents.backgroundThrottling 设置为 false 将影响所有的 WebContents。​

将 WebContents.backgroundThrottling 设置为 false 将禁用由 BrowserWindow 显示的所有 WebContents 的帧节流。

移除: BrowserWindow.setTrafficLightPosition(position)​

已经移除了 BrowserWindow.setTrafficLightPosition(position) 方法,应该改用 BrowserWindow.setWindowButtonPosition(position)方法。新的方法接受 null 作为替换 { x: 0, y: 0 } 的参数,以将位置重置为系统默认值。

// 在 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 代替,当没有自定义位置时,它返回 null 而不是 { x: 0, y: 0 }。

// 在 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 来替代它

IpcRendererEvent 的 senderId 和 senderIsMainFrame 属性也已经被移除。

移除: app.runningUnderRosettaTranslation​

app.runningUnderRosettaTranslation 属性已经被移除。 使用 app.runningUnderARM64Translation 代替.

// 移除
console.log(app.runningUnderRosettaTranslation);
// 代替为
console.log(app.runningUnderARM64Translation);

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

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

E28(23 年 12 月)E29(24 年 2 月)E30(24 年 4 月)
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y
26.x.y27.x.y28.x.y

接下来​

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

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

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

回顾 2023 年生态系统

· 阅读时间:约 8 分钟

回顾 2023 年 Electron 开发者生态系统的改进和变化。


过去几个月里,我们在整个 Electron 生态系统中进行一些优化,以提升 Electron 应用程序的开发者体验! 这是 Electron HQ 最新增加的项目的快速概述。

Electron Forge 7 及其以后​

Electron Forge 7 — 用于打包和分发 Electron 应用程序的一体化工具的最新主要版本 — 现已发布。

虽然 Forge 6 与 v5 是完全重写的,但 v7 的范围较小,但仍包含一些重大变更。 未来,我们将继续发布 Forge 的主要版本,以便进行必要的重大变更。

欲了解更多详情,请参阅 GitHub 上的完整描述 Forge v7.0.0 更新日志。

重大变更​

  • 切换 macOS notarization 工具到 notarytool: 截至2023-11-01。 苹果废弃了 macOS notarization 的传统工具 altool,此次发布将其从 Electron Forge 中完全删除。
  • 最小 Node.js 支持增加到 v16.4.0: 在这个版本中,我们已将所需版本的 Node.js 设置为 16.4.0。
  • 废弃了对 electron-prebuild 和 electron-prebuild-compile 的支持: electron-prebuild 是 electron npm 模块的原始名称的支持,但在 v1.3.1 中 被 electron 代替了。 electron-prebuild-compile 是一个带有增强开发体验功能的二进制文件的替代方案,但最终作为一个项目被放弃了。

重点内容​

  • Google Cloud Storage 发布器: 作为我们推动更好地支持静态自动更新的一部分,Electron Forge 现在支持直接发布到 Google Cloud Storage!
  • ESM forge.config.js 支持: Electron Forge 现在支持 ESM forge.config.js 文件。 (附言: 期待在 Electron 28 中支持 ESM entrypoint。)
  • Makers 现在可以并行运行: 在 Electron Forge 6 中 Makers 由于 ✨ 遗产 ✨ 原因而顺序运行。 从那时起,我们已经测试了使用并行 Make 步骤的效果,并且没有出现任何负面影响。 当在同一平台上构建多个目标时,你应该会看到加速效果!
非常感谢!

🙇 对于 mahnunchik 为 GCS Publisher 和 Forge 配置中支持 ESM 的贡献,表示衷心感谢!

静态存储自动更新的改进​

Squirel.Windows 和 Squirrel.Mac 是支持 Electron 的内置 autoUpdater 模块的特定平台更新技术。 两个项目都支持通过两种方法自动更新:

  • 一个与 Squirrel 兼容的更新服务器
  • 在静态存储提供商上托管的清单 URL (例如 AWS、谷歌云平台、微软 Azure 等)

传统上,更新服务器方法一直被认为是 Electron 应用的推荐方法(并提供了额外的更新逻辑自定义),但它也有一个主要的缺点 — 如果应用是闭源的,它需要维护自己的服务器实例。

另一方面,虽然静态存储方法一直是可行的,但在 Electron 内部没有文档记录,并且在 Electron 工具包中支持不足。

通过 @MarshallOfSound 的杰出工作,无服务器自动应用程序更新已经得到了显著简化:

  • Electron Forge 的 Zip 和 Squirrel.Windows 制作工具现在可以配置为输出与 autoUpdater 兼容的更新清单。
  • 现在,update-electron-app 的一个新的主要版本(v2.0.0)可以读取这些生成的清单,作为 update.electronjs.org 服务器的替代方案。

一旦你的 Makers 和 Publishers 配置好了并上传更新清单到云文件存储,你只需要几行配置代码就可以启用自动更新。

const { updateElectronApp, UpdateSourceType } = require('update-electron-app');

updateElectronApp({
updateSource: {
type: UpdateSourceType.StaticStorage,
baseUrl: `https://my-manifest.url/${process.platform}/${process.arch}`,
},
});
延伸阅读

📦 想要了解更多? 详细指南见 Forge 的自动更新文档。

@electron/ 扩展宇宙​

Electron 刚开始时,社区发布了许多软件包,以增强开发、包装和分发 Electron 应用的体验。 随着时间的推移,其中许多软件包都被纳入 Electron 的 GitHub 组织,核心团队承担了维护负担。

在2022年,我们开始将所有这些 first-party 工具整合到 npm 的 @electron/ 命名空间下。 此变更意味着以前被称为 electron-foo 的软件包现在在 npm上被称为 @electron/foo,而以前命名为 electron/electron-foo 的仓库现在在 GitHub 上被称为 electron/foo。 这些变化有助于明确划分 first-party 项目和 userland 项目。 这包括许多常用的软件包,例如:

  • @electron/asar
  • @electron/fuses
  • @electron/get
  • @electron/notarize
  • @electron/osx-sign
  • @electron/packager
  • @electron/rebuild
  • @electron/remote
  • @electron/symbolicate-mac
  • @electron/universal

从现在开始,我们发布的所有 first-party 软件包都将在 @electron/ 命名空间中。 这条规则有两个例外情况:

  • Electron 核心将继续在 electron 软件包下发布。
  • Electron Forge 将继续在 @electron-forge/ namespace 下发布其所有的 monorepo 软件包。
寻找 Star

⭐ 在这个过程中,我们意外地将 electron/packager 仓库设为私有,这不幸地导致我们的 GitHub 星星计数被删除(擦除之前超过9000颗)。 如果你是 Packager 的活跃用户,我们将非常感谢你的 ⭐ Star ⭐ !

介绍 @electron/windows-sign​

从 2023 年 6 月 1日开始,行业标准要求 Windows 代码签名证书的密钥必须存储在符合 FIPS 标准的硬件上。

在实践中,这意味着对于在 CI 环境中构建和签名的应用来说,代码签名变得更加困难,因为许多 Electron 工具使用证书文件和密码作为配置参数,并尝试使用硬编码逻辑从中进行签名。

这种情况对于 Electron 开发人员来说是一个常见的痛点,这就是为什么我们一直在努力寻找一个更好的解决方案,将 Windows 代码签名独立到一个单独的步骤中,类似于 @electron/osx-sign 在 macOS 上的做法。

在未来,我们计划将此软件包完全整合到 Electron Forge 工具链中,但目前它独立存在。 该软件包目前可通过 npm install --save-dev @electron/windows-sign 进行安装,并可通过编程或命令行界面(CLI)进行使用。

请尝试在项目的 issue 跟踪器中给我们反馈!

下一步​

我们将在下个月进入我们每年 12 月安静的时期。 在这样做的同时,我们将考虑如何在 2024 年使 Electron 开发体验更好。

你是否希望看到我们接下来的工作? 请告诉我们!

12月安静期(2023年12月)

· 阅读时间:约 2 分钟

The Electron project will pause for the month of December 2023, then return to full speed in January 2024.

via GIPHY


12月保持不变的内容​

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

12月变动的内容​

  1. Electron 28.0.0 will be released on December 5th. After Electron 28, there will be no new Stable releases in December.
  2. 12 月的最后两周没有 Nightly 和 Alpha 版本。
  3. 除了少数例外,不会合并请求的审核或合并。
  4. 任何仓库上都不会有问题跟进更新。
  5. 维护人员不会提供 Discord 调试帮助。
  6. 社交媒体暂停更新内容。

Going forward​

This is our third year running our quiet period experiment, and we've had a lot of success so far in balancing a month of rest with maintaining our normal release cadence afterwards. Therefore, we've decided to make this a regular part of our release calendar going forward. We'll still be putting a reminder into the last stable release of every calendar year.

See you all in 2024!

Electron 27.0.0

· 阅读时间:约 5 分钟

Electron 27.0.0 已发布! 此次升级中包含 Chromium 118.0.5993.32,V8 11.8,和 Node.js 18.17.1。


Electron 团队很高兴发布了 Electron 27.0.0! 您可以通过 npm install electron@latest 进行安装,或者从我们的 发布网站 下载它。 继续阅读此版本的详细信息。

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

重要变化​

架构(Stack)更新​

重大更改​

已移除:macOS 10.13 / 10.14 / 支援​

macOS 10.13 (High Serria) 和 macOS 10.14 (Mojave) 不再支援Chromium.

旧版本的 Electron 将继续在这些操作系统上运行,但需要 macOS 10.15 (Catalina) 或更高版本才能运行 Electron v27.0.0 及更高版本。

弃用:ipcRenderer.sendTo()​

ipcRenderer.sendTo() 已被弃用。 可以通过在渲染器之间设置一个 MessageChannel 来替换它。

IpcRendererEvent 的 senderId 和 senderIsMainFrame 属性也已被弃用。

已删除: systemPreferences 中的 color scheme 相关事件​

以下 systemPreferences 事件已被删除:

  • inverted-color-scheme-changed
  • high-contrast-color-scheme-changed

请改用 nativeTheme 模块上的新 updated 事件。

// 已删除
systemPreferences.on('inverted-color-scheme-changed', () => {
/* ... */
});
systemPreferences.on('high-contrast-color-scheme-changed', () => {
/* ... */
});

// 替换为
nativeTheme.on('updated', () => {
/* ... */
});

已删除: webContents.getPrinters​

webContents.getPrinters 方法已被删除。 使用webContents.getPrintersAsync代替。

const w = new BrowserWindow({ show: false });

// 已删除
console.log(w.webContents.getPrinters());
// 替换为
w.webContents.getPrintersAsync().then((printers) => {
console.log(printers);
});

已删除:systemPreferences.{get,set}AppLevelAppearance 和 systemPreferences.appLevelAppearance​

方法 systemPreferences.getAppLevelAppearance 和 systemPreferences.setAppLevelAppearance 已被删除,也包括属性 systemPreferences.appLevelAppearance。 请改用模块 nativeTheme。

// 已删除
systemPreferences.getAppLevelAppearance();
// 替换为
nativeTheme.shouldUseDarkColors;

// 已删除
systemPreferences.appLevelAppearance;
// 替换为
nativeTheme.shouldUseDarkColors;

// 已删除
systemPreferences.setAppLevelAppearance('dark');
// 替换为
nativeTheme.themeSource = 'dark';

已删除:systemPreferences.getColor 的 alternate-selected-control-text 值​

systemPreferences.getColor 的 alternate-selected-control-text 值已被删除。 替换为 selected-content-background。

// 已删除
systemPreferences.getColor('alternate-selected-control-text');
// 替换为
systemPreferences.getColor('selected-content-background');

新特性​

  • 添加了应用可访问性透明度设置 API #39631
  • 添加了对 chrome.scripting 扩展 API 的支持 #39675
  • 默认启用 WaylandWindowDecorations #39644

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

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

E27(23 年 10 月)E22 (23 年 12 月)E29(24 年 2 月)
27.x.y28.x.y29.x.y
26.x.y27.x.y28.x.y
25.x.y26.x.y27.x.y

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

今年早些时候,Electron 团队将 Electron 22 的计划生命终止日期从 2023 年 5 月 30 日延长至 2023 年 10 月 10 日,以配合 Chrome 对 Windows 7/8/8.1 的扩展支持(详情请查看 Farewell, Windows 7/8/8.1)。

根据项目的支持政策和此支持扩展,Electron 22.x.y 已经达到了支持的终点。 这将恢复到支持最新的三个稳定的主要版本,并将结束对 Windows 7/8.1 的官方支持。

接下来​

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

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

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

Breach to Barrier: Strengthening Apps with the Sandbox

· 阅读时间:约 7 分钟

距离 CVE-2023-4863: 在WebP图片中的堆栈溢出 被公开已经过去了一个星期多。这导致众多渲染 webp 图片的软件都得到了更新:macOS, iOS, Chrome, Firefox 和众多 Linux 发行版都发布了更新。 这是在Citizen Lab进行调查之后进行的。他们发现 “设在华盛顿特区的民间组织” 使用的iPhone通过零点击漏洞在iMessage中被攻击。

Electron也在同一天发布新版本:如果您的应用会显示任何用户提供的内容 您应该更新您的 Electron 版本 - v27 0.0-beta.2, v26.2.1, v25.8.1, v24.8.3, v22.3.24 均包括已经过修复的 libwebp,一个负责渲染 webp 图像的库。

既然我们大家都新近意识到, 像“渲染一幅图片” 这样看似无害的交互是一种潜在的危险活动, 我们要借此机会提醒大家,Electron包括的进程沙盒将限制下一次大型攻击的猛烈程度,无论它将会是什么。

沙盒从 Electron v1 开始可用,并在 v20 默认情况下启用。 但我们知道许多应用 (尤其是那些已经存在有一段时间的应用) 可能会在其代码中的某个地方有一个 sandbox: false 或 nodeIntegration: true,这则配置在当没有明确的 sandbox 设置时同样禁用沙盒。 这是可以理解的:如果你已经使用Electron很长时间,你可能已经感受到了 require("child_process") 或 require("fs") 直接扔进运行你的 HTML/CSS 的代码带来的力量。

在我们讨论你能够_如何_迁移到沙盒内之前,我们不如首先讨论你_为什么_会想要迁移。

沙盒围绕所有渲染进程设置了一个保护机制。这确保不论内部发生什么,代码都在受限制的环境中执行。 作为一个概念,它比Chromium老得多,并且所有主流的操作系统都提供了这个功能。 Electron和Chromium的沙盒搭建在这些系统功能之上。 即使您从未显示用户生成的内容,你应该考虑到你的渲染器可能受到损害的可能性:场景像供应链攻击一样复杂,并且很简单,因为小的bug可能会导致你的渲染器做意想不到的事。

沙盒使情景变得更安全:一个在沙盒内的进程可以免费使用 CPU 资源和内存 — 就没别的了。 进程不能写入磁盘或显示自己的窗口。 就我们的 libwep bug而言,沙盒确保攻击者无法安装或运行恶意程序。 事实上,在最初 Pegasus 袭击雇员 iPhone 的案件中,袭击具体针对的是一个非沙盒图像进程以获得对手机的访问权限,打破了正常情况下 iMessage 沙盒的界限。 当一个CVE像这个示例中的那样被宣布时,您仍然须将您的 Electron 应用程序升级到安全版本 — 不过与此同时,攻击者能够造成的损害受到极大的限制。

将原版Electron应用程序从 sandbox: false 迁移到 sandbox: true 是一项较大的任务。 我理解,因为即使我亲自撰写了 Electron 安全准则,我还没有设法迁移我自己的一个应用来使用该项准则。 在这个周末,我把它改掉了,我建议你也这么做。

别被修改行数的体量吓到,这些大多都在 package-lock.json 里。

你需要处理两件事:

  1. 如果您在 preload 脚本或实际的 WebContents 中使用Node.js 代码,您需要将所有以上这些与 Node.js 的交互迁移到主进程 (或者,如果你愿意的话,一个多用途进程) 。 考虑到最近渲染器正在变得越来越强大,很有可能你的代码很大一部分其实并不需要重构。

    查阅我们对于 进程间通信 的文档。 就我而言,我移动了许多代码,并用 ipcRenderer.invoke() 和 ipcMain.handle()包装了它,但是这个过程是直截了当的,而且很快就完成了。 请稍微注意你的 API - 如果你构建一个名为 executeCodeAsRoot(code)的API,沙盒将不会过多地保护你的用户。

  2. 因为启用沙盒会在您的预加载脚本中禁用对 Node.js 的集成,你不再能使用require("../my-script")。 换言之,您的预加载脚本需要是一个单一的文件。

    这样做有多种方式:Webpack、esbuild、parcel 和 rollup 都能办到。 我使用 Electron Forge的出色Webpack插件,而同样受欢迎的 electron-builder 用户可以使用 electron-webpack。

总的来讲,整个过程花了我四天时间 — 而这包括很多,由于我决定利用这次机会通过其他方式去重构我的代码而产生的,对于如何最大化 Webpack 众多效用的思考。

Electron 26.0.0

· 阅读时间:约 3 分钟

Electron 26.0.0 已发布! 此次升级中包含 Chromium 116.0.5845.62,V8 11.2,和 Node.js 18.16.1 。 请阅读下文了解更多详情!


Electron 团队很高兴发布了 Electron 26.0.0 ! 您可以通过 npm install electron@latest 进行安装,或者从我们的 发布网站 下载它。 继续阅读此版本的详细信息。

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

重要变化​

架构(Stack)更新​

重大更改​

弃用:webContents.getPrinters​

webContents.getPrinters 方法已经被废除。 使用webContents.getPrintersAsync代替。

const w = new BrowserWindow({ show: false });

// 被弃用
console.log(w.webContents.getPrinters());
// 使用它来代替
w.webContents.getPrintersAsync().then((printers) => {
console.log(printers);
});

弃用:systemPreferences.{get,set}AppLevelAppearance 和 systemPreferences.appLevelAppearance​

方法systemPreferences.getAppLevelAppearance 和 systemPreferences.setAppLevelAppearance 已被弃用,也包括属性 systemPreferences.appLevelAppearance。 请改用模块 nativeTheme。

// 被弃用
systemPreferences.getAppLevelAppearance();
// 替换为
nativeTheme.shouldUseDarkColors;

// 被弃用
systemPreferences.appLevelAppearance;
// 替换为
nativeTheme.shouldUseDarkColors;

// 被弃用
systemPreferences.setAppLevelAppearance('dark');
// 替换为
nativeTheme.themeSource = 'dark';

弃用:systemPreferences.getColor 的 alternate-selected-control-text 值​

systemPreferences.getColor 的 alternate-selected-control-text 值已被弃用。 替换为 selected-content-background。

// 被弃用
systemPreferences.getColor('alternate-selected-control-text');
// 替换为
systemPreferences.getColor('selected-content-background');

新特性​

  • 添加了 safeStorage.setUsePlainTextEncryption 和 safeStorage.getSelectedStorageBackend api。 #39107
  • 添加了 safeStorage.setUsePlainTextEncryption 和 safeStorage.getSelectedStorageBackend api。 #39155
  • 将senderIsMainFrame添加到通过ipcRenderer.sendTo()发送的消息中。 #39206
  • 添加了由键盘初始化菜单弹出的支持。 #38954

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

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

E26(23 年 8月)E27(23 年 10 月)E28(24 年 1 月)
26.x.y27.x.y28.x.y
25.x.y26.x.y27.x.y
24.x.y25.x.y26.x.y
22.x.y

接下来​

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

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

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

Electron 25.0.0

· 阅读时间:约 6 分钟

Electron 25.0.0 已发布! 此次升级中包含 Chromium 114,V8 11.4,和 Node.js 18.15.0 。 请阅读下文了解更多详情!


Electron 团队很高兴发布了 Electron 25.0.0 ! 您可以通过 npm install electron@latest 进行安装,或者从我们的 发布网站 下载它。 继续阅读此版本的详细信息。

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

重要变化​

重点内容​

  • 使用 Chromium 的网络栈在 Electron 的 net 模块中实现了 net.fetch。 和 Node 的 fetch() 不同的是后者使用了 Node.js 的 HTTP 栈。 请参阅 #36733 和 #36606。
  • 添加了 protocol.handle,它取代并弃用了 protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol。 #36674
  • 增加了对 Electron 22 的支持,以配合 Chromium 和 Microsoft 的 Windows 7/8/8.1 弃用计划。 请参阅本博文末尾的更多详细信息。

架构(Stack)更新​

重大更改​

弃用:protocol.{register,intercept}{Buffer,String,Stream,File,Http}Protocol​

protocol.register***Protocol 和 protocol.intercept***Protocol 方法 已替换为 protocol.handle。

新方法可以注册新协议或拦截现有协议 协议和响应可以是任何类型。

// 在 Electron 25 中弃用
protocol.registerBufferProtocol('some-protocol', () => {
callback({ mimeType: 'text/html', data: Buffer.from('<h5>Response</h5>') });
});

// 用以代替
protocol.handle('some-protocol', () => {
return new Response(
Buffer.from('<h5>Response</h5>'), // 也可以是 string 或 ReadableStream.
{ headers: { 'content-type': 'text/html' } },
);
});
// 在 Electron 25 中弃用
protocol.registerHttpProtocol('some-protocol', () => {
callback({ url: 'https://electronjs.org' });
});

// 用以代替
protocol.handle('some-protocol', () => {
return net.fetch('https://electronjs.org');
});
// 在 Electron 25 中弃用
protocol.registerFileProtocol('some-protocol', () => {
callback({ filePath: '/path/to/my/file' });
});

// 用以代替
protocol.handle('some-protocol', () => {
return net.fetch('file:///path/to/my/file');
});

弃用:BrowserWindow.setTrafficLightPosition(position)​

BrowserWindow.setTrafficLightPosition(position) 已弃用,应使用 BrowserWindow.setWindowButtonPosition(position) API,它接受 null 而不是 { x: 0, y: 0 } 将位置重置为系统默认值。

// 在 Electron 25 中弃用
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,当没有自定义位置时,它返回 null 而不是 { x: 0, y: 0 } 。

// Deprecated in Electron 25
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
// No custom position.
}

// Replace with
const ret = win.getWindowButtonPosition();
if (ret === null) {
// No custom position.
}

新特性​

  • 已添加 net.fetch()。 #36733
    • net.fetch 支持对 file: URL 和使用 protocol.register*Protocol 注册的自定义协议的请求。 #36606
  • 添加了 BrowserWindow.set/getWindowButtonPosition API。 #37094
  • 添加了protocol.handle,替换并弃用了protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol。 #36674
  • 向 webContents 和 <webview> 标签添加了一个 will-frame-navigate 事件,每当 frame 层中的任何一个 frame 调用 navigate 时,都会触发该函数。 #34418
  • 向 navigator 事件添加了启动信息。 这个信息允许区分来自父框架 window.open 引起的 navigation 事件,而不是来自子框架发起的 navigation 事件。 #37085
  • 增加了 net.resolveHost,它使用 defaultSession 对象来解析 hosts。 #38152
  • 向 app 添加了新的 'did-resign-active' 事件。 #38018
  • 向 webContents.print() 添加了几个标准页面大小选项。 #37159
  • 向会话处理程序 ses.setDisplayMediaRequestHandler() 的回调中添加了 enableLocalEcho 标志,以允许当 audio 为 WebFrameMain 时在本地输出流中回显远程音频输入。 #37315
  • 向 powerMonitor 添加了 thermal 信息管理。 #38028
  • 允许将绝对路径传递给 session.fromPath() API。 #37604
  • 在 webContents 上公开 audio-state-changed 事件。 #37366

22.x.y 持续支持​

正如再见 Windows 7/8/8.1 所述,Electron 22(Chromium 108)的计划寿命终止日期将从 2023 年 5 月 30 日延长至 2023 年 10 月 10 日。 Electron 团队将会继续向 Electron 22 提供本计划中的任何安全修复,直到 2023 年 10 月 10 日。 十月 支持日期遵循 Chromium 和 Microsoft 的延长支持日期。 10 月 11 日,Electron 团队将支持回退到最新的三个稳定主要版本,将不再支持 Windows 7/8/8.1。

E25(23 年 5 月)E26(23 年 8月)E27(23 年 10 月)
25.x.y26.x.y27.x.y
24.x.y25.x.y26.x.y
23.x.y24.x.y25.x.y
22.x.y22.x.y--

接下来​

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

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

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