Electron 正在暂停更新大型版本
我们的 大型更新时间表 与Chromium 同步更新，Chromium项目最近由于调整工作时间表已决定 暂停更新。 这意味着，在Chromium经过改变的更新节奏期间，Electron也会暂时性地暂停重大更新。
我们认为，我们的最佳选择是沿着Chromium的脚步走下去， 因此，在过渡时期，Electron团队将转为全天候处理错误、安全、性能和稳定性问题。
我们希望确保我们的维护者和消费者的福利在这个时候都得到优先考虑。 因此，我们欢迎你们的反馈，并期待着恢复我们的正常发布时间表。
欲了解更多更新信息，请关注我们的 Twitter。
编辑(2020-03-30)：Election 9 稳定版将针对Chromium M83，并于2020年5月19日发布。 这针对 Chromium的声明 关于跳过M82稳定日期并调整M83稳定版发布日期。
Electron 8.0.0 已发布！ 它包括升级到 Chromium 80, V8 8.0, 和 Node.js 12.13.0。 We've added Chrome's built-in spellchecker, and much more!
Electron 团队很高兴发布了 Electron 8.0.0.0！ 您可以通过 npm 安装electron@later 或者从我们的 发布网站 下载它。 这次发布包含升级、修复和新功能。 We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!
80.0.3987.86
12.13.0
8.0
有关新功能和变更的完整列表，请参阅 8.0.0 发布通知 。
有关这些和未来变化的更多信息可在 计划的破坏性变化 页面找到。
app API changes:
BrowserWindow API changes:
hasShadow is available on all platforms #20038trafficLightPosition option to BrowserWindow options to allow custom positioning for traffic light buttons. #21781accessibleTitle option to BrowserWindow for setting the accessible window title #19698BrowserWindow.fromWebContents() can now return null #19983BrowserWindow.getMediaSourceId() and BrowserWindow.moveAbove(mediaSourceId). #18926will-move event on macOS. #19641crashReporter.getCrashesDirectory(). #20417dialog API changes:
Notification API changes:
session API changes:
session.setProxy(config) and session.setCertificateVerifyProc(proc) to note optional options. #19604session.downloadURL(url) to allow to triggering downloads without a BrowserWindow. #19889session.preconnect(options) and the preconnect event. #18671session.addWordToSpellCheckerDictionary to allow custom words in the dictionary #21297shell.moveItemToTrash(fullPath[, deleteOnFail]) on macOS to specify what happens when moveItemToTrash fails. #19700systemPreferences API changes:
nativeTheme.themeSource to allow apps to override Chromium and the OS's theme choice. #19960tray API changes:
webContents API changes:
contents.executeJavaScriptInIsolatedWorld(worldId, scripts[, userGesture]) to expose executeJavaScriptInIsolatedWorld on the webContents API. #21190webContents.print([options], [callback]) to enable customization of print page headers and footers. #19688webContents.getAllSharedWorkers() and webContents.inspectSharedWorkerById(workerId). #20389fitToPageEnabled and scaleFactor options in WebContents.printToPDF(). #20436webview.printToPDF documentation to indicate return type is now Uint8Array. #20505The following APIs are now deprecated:
visibleOnFullScreen option within BrowserWindow.setVisibleOnAllWorkspaces prior to its removal in the next major release version. #21732alternate-selected-control-text on systemPreferences.getColor(color) for macOS. #20611setLayoutZoomLevelLimits on webContents, webFrame, and <webview> Tag because Chromium removed this capability. #21296false for app.allowRendererProcessReuse is now deprecated. #21287<webview>.getWebContents() as it depends on the remote module. #20726Electron 5.x.y has reached end-of-support as per the project's support policy. 我们鼓励开发者将应用程序升级到更新的 Electron 版本。
We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.
在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。 尽管我们谨慎地避免对发布日期做出承诺，但我们的计划是大约每季度发布一次 Electron 的新主要版本以及这些组件的新版本。 暂定 9.0.0 时间表 展示了 Electron 9 开发生命周期中的关键日期。 Also, see our versioning document for more detailed information about versioning in Electron.
For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.
remote Module (Starting in Electron 9)Due to serious security liabilities, we are beginning plans to deprecate the remote module starting in Electron 9. You can read and follow this issue that details our reasons for this and includes a proposed timeline for deprecation.
At Node+JS Interactive in Montreal, the OpenJS Foundation announced that it accepted Electron into the Foundation's incubation program. The Foundation is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects, as well as collaboratively fund activities for the benefit of the community at large.
The OpenJS Foundation is host to a number of open source JavaScript projects including jQuery, Node.js, and webpack. It's supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft. Electron is an open–source framework for building cross-platform desktop applications with web technologies.
This is an exciting move for Electron, and we see it as a next step in our evolution as an open-source project.
Electron joining the OpenJS Foundation does not change how Electron is made, released, or used — and does not directly affect developers building applications with Electron. Even though Electron was originally created at GitHub in 2013, it is currently maintained by a number of organizations and individuals. In 2019, Electron codified its governance structure and invested heavily into formalizing how decisions affecting the entire project are made. We believe that having multiple organizations and developers investing in and collaborating on Electron makes the project stronger.
Lifting Electron up from being owned by a single corporate entity and moving it into a neutral foundation focused on supporting the web and JavaScript ecosystem is a natural next step as we mature as an open-source project.
You can read up on the foundation, its mission, and its members on the OpenJSF website. For more information and quotes about the acceptance of Electron into the OpenJSF incubation program, check out the official press release. To learn more about the humans behind Electron and how they work together, take a look at our Governance page.
To get started with Electron itself, take a peek at our documentation.
A High severity vulnerability has been discovered in Chrome which affects all software based on Chromium, including Electron.
此漏洞已被分配 CVE-2019-13720。 您可以在 Chrome 博客文章 中阅读更多关于它的信息。
请注意，Chrome将这个漏洞报告为已经被利用，因此强烈建议您尽快升级 Electron
This affects any Electron application that may run third-party or untrusted JavaScript.
Affected apps should upgrade to a patched version of Electron.
We've published new versions of Electron which include fixes for this vulnerability:
Electron 7.0.1 在发布通知之前已自动包含了上游的修复。 Electron 8同样不受影响。 该漏洞在Electron 5中不存在，因此该版本也不受影响。
此漏洞由卡巴斯基实验室的 Anton Ivanov 和 Alexey Kulaev 发现，并报告给 Chrome 团队。 Chrome博客文章可以在这里找到 。
要了解更多关于维护您的 Electron 应用安全的最佳做法，请参阅我们的 安全教程。
If you wish to report a vulnerability in Electron, email security@electronjs.org.
Electron 7.0.0 已发布！ 它包括升级Chromium 78, V8 7.8和Node.js 12.8.1。 我们已经添加了一个窗口到Arm 64版本，更快的 IPC 方法，一个新的 本地主题 API，还有更多！
Electron 团队很高兴发布了 Electron 7.0.0.0！ 您可以通过 npm 安装electron@later 或者从我们的 发布网站 下载它。 这次发布包含升级、修复和新功能。 We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!
Stack Upgrades:
| Stack | Version in Electron 6 | Version in Electron 7 | What's New |
|---|---|---|---|
| Chromium | 76.0.3809.146 | 78.0.3905.1 | 77, 78 |
| V8 | 7.6 | 7.8 | 7.7, 7.8 |
| Node.js | 12.4.0 | 12.8.1 | 12.5, 12.6, 12.7, 12.8, 12.8.1 |
Added ipcRenderer.invoke() and ipcMain.handle() for asynchronous request/response-style IPC. These are strongly recommended over the remote module. See this "Electron’s ‘remote’ module considered harmful" blog post for more information. #18449
Added nativeTheme API to read and respond to changes in the OS's theme and color scheme. #19758, #20486
Switched to a new TypeScript Definitions generator. The resulting definitions are more precise; so if your TypeScript build fails, this is the likely cause. #18103
See the 7.0.0 release notes for a longer list of changes.
有关这些和未来变化的更多信息可在 计划的破坏性变化 页面找到。
Tray.setHighlightMode() (macOS). #18981app.enableMixedSandbox() #17894app.getApplicationMenu(),app.setApplicationMenu(),powerMonitor.querySystemIdleState(),powerMonitor.querySystemIdleTime(),webFrame.setIsolatedWorldContentSecurityPolicy(),webFrame.setIsolatedWorldHumanReadableName(),webFrame.setIsolatedWorldSecurityOrigin() #18159Session.clearAuthCache() no longer allows filtering the cleared cache entries. #17970electron module to use @electron/get. The minimum supported node version is now Node 8. #18413electron.asar no longer exists. Any packaging scripts that depend on its existence should be updated. #18577Electron 4.x.y has reached end-of-support as per the project's support policy. 我们鼓励开发者将应用程序升级到更新的 Electron 版本。
We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.
在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。 尽管我们谨慎地避免对发布日期做出承诺，但我们的计划是大约每季度发布一次 Electron 的新主要版本以及这些组件的新版本。 暂定 8.0.0 时间表 展示了 Electron 8 开发生命周期中的关键日期。 Also, see our versioning document for more detailed information about versioning in Electron.
For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.
Electron 团队很高兴发布了 Electron 6.0.0.0！ 您可以通过 npm 安装electron@later 或者从我们的 发布网站 下载它。 这次发布包含升级、修复和新功能。 We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!
Today marks a first for the Electron project: this is the first time we've made a stable Electron release on the same day as the corresponding Chrome stable release! 🎉
Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 6:
76.0.3809.88
12.4.0
7.6.303.22
This release also includes improvements to Electron's APIs. The release notes have a more complete list, but here are the highlights:
Electron 6.0 continues the modernization initiative started in 5.0 to improve Promise support.
These functions now return Promises and still support older callback-based invocation:
contentTracing.getCategories() #16583contentTracing.getCategories() #16583contentTracking.getTraceBufferUs() #16600contents.executeJavaScript() #17312cookies.flushStore() #16464cookies.get() #16464cookies.remove() #16464cookies.set() #16464dialog.showCertificateTrustDialog() #17181inAppPurchase.getProducts() #17355inAppPurchase.purchaseProduct()#17355netLog.stopLogging() #16862session.clearAuthCache() #17259session.clearCache() #17185session.clearHostResolverCache() #17229session.clearStorageData() #17249session.getBlobData() #17303session.getCacheSize() #17185session.resolveProxy() #17222session.setProxy() #17222webContents.hasServiceWorker() #16535webContents.printToPDF() #16795webContents.savePage() #16742webFrame.executeJavaScript() #17312webFrame.executeJavaScriptInIsolatedWorld() #17312webviewTag.executeJavaScript() #17312这些功能现在有两种形式，即同步和基于Promise的异步：
dialog.showMessageBox()/dialog.showMessageBoxSync() #17298dialog.showOpenDialog()/dialog.showOpenDialogSync() #16973dialog.showSaveDialog()/dialog.showSaveDialogSync() #17054These functions now return Promises:
app.dock.show() #16904Electron Helper (Renderer).app, Electron Helper (GPU).app and Electron Helper (Plugin).appIn order to enable the hardened runtime, which restricts things like writable-executable memory and loading code signed by a different Team ID, special code signing entitlements needed to be granted to the Helper.
To keep these entitlements scoped to the process types that require them, Chromium added three new variants of the Helper app: one for renderers (Electron Helper (Renderer).app), one for the GPU process (Electron Helper (GPU).app) and one for plugins (Electron Helper (Plugin).app).
Folks using electron-osx-sign to codesign their Electron app shouldn't have to make any changes to their build logic. If you're codesigning your app with custom scripts, you should ensure that the three new Helper applications are correctly codesigned.
In order to package your application correctly with these new helpers you need to be using electron-packager@14.0.4 or higher. If you are using electron-builder you should follow this issue to track support for these new helpers.
This release begins laying the groundwork for a future requirement that native Node modules loaded in the renderer process be either N-API or Context Aware. The reasons for this change are faster performance, stronger security, and reduced maintenance workload. Read the full details including the proposed timeline in this issue. This change is expected to be completed in Electron v11.
net.IncomingMessage headers have changed slightly to more closely match Node.js behavior, particularly with the value of set-cookie and how duplicate headers are handled. #17517.
shell.showItemInFolder() now returns void and is an asynchronous call. #17121
Apps must now explicitly set a log path by calling the new function app.setAppLogPath() before using app.getPath('log'). #17841
Per our support policy, 3.x.y has reached end of life. 我们鼓励开发者将应用程序升级到更新的 Electron 版本。
We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.
在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。 尽管我们谨慎地避免对发布日期做出承诺，但我们的计划是大约每季度发布一次 Electron 的新主要版本以及这些组件的新版本。 暂定 7.0.0 时间表 展示了 Electron 7 开发生命周期中的关键日期。 Also, see our versioning document for more detailed information about versioning in Electron.
For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.
🎉 Electron 每12周将会新发布一个稳定版本！ 🎉
简而言之，Chromium 不会停止发布新版本，所以 Electron 的研发也不会减速。
Chromium 的发布遵循每六周更新一次的规划。 为了在Electron中提供最新版本的Chromium，我们的发布计划需要跟踪他们的版本。 有关Chromium发布周期的更多信息可以在这里找到 。
每6周，新的 Chromium 版本就会发布新功能，错误 / 安全修复和 V8 的改进。 Electron 用户一直迫切明确地表示希望这些更改能及时进行，因此我们调整了稳定发布日期，以匹配其他所有Chromium 稳定版本。 首先，Electron v6.0.0 将包括 M76，并计划于2019年7月30日发布稳定版，与Chromium M76同一天发布。
您将能比以前更快地访问新的 Chromium 和 V8 功能和补丁。 重要的是，_当这些新变化到来时_您也能知道，因此您将能够使用比以前更好的信息进行规划。
Electron 团队 将继续支持 最新的三个主要版本。 例如，当 v6.0.0 在 2019 年 7 月 30 日稳定时，我们将继续支持 v6.x、v5.x 和 v4.x，而 v3.x 将寿终正寝。
请考虑加入我们的 应用反馈计划 ，以帮助我们测试 Beta 版和应用稳定性。 Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release.
在 v3.0.0 之前，有关稳定版本的发布决策没有规律进行。 我们添加了项目的内部时间表与 v3.0.0 和 v4.0.0。 今年早些时候，我们决定首次发布 Electron v5.0.0 的稳定发布日期。 总的来说，宣布我们的稳定发布日期得到了积极的回应，我们很高兴在未来的版本中继续这样做。
为了更好地简化这些与升级相关的工作，我们的更新和发布工作组将会和我们的治理组合作 他们使得我们能够更好地确定这项工作的优先级并委派这项工作，我们希望在后续的版本中这些改变都会变得更加明显。
以下是我们和 Chromium 相比的更新计划表：
📨 如果您有任何疑问，请发送电子邮件至 info@electronjs.org。
Electron 团队很高兴发布了 Electron 5.0.0.0！ You can install it with npm via npm install electron@latest or download the tarballs from our releases page. 这次发布包含升级、修复和新功能。 We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!
Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 5:
73.0.3683.119
12.0.0
7.3.492.27.
Electron 5 also includes improvements to Electron-specific APIs. A summary of the major changes is below; for the full list of changes, check out the Electron v5.0.0 release notes.
Electron 5 continues Promisification initiative initiative to convert Electron's callback-based API to use Promises. These APIs were converted for Electron 5:
app.getFileIconcontentTracing.getCategoriescontentTracing.startRecordingcontentTracing.stopRecordingdebugger.sendCommandshell.openExternalwebContents.loadFilewebContents.loadURLwebContents.zoomLevelwebContents.zoomFactorwin.capturePageThese functions were changed or added to systemPreferences to access macOS systems' colors:
systemPreferences.getAccentColorsystemPreferences.getColorsystemPreferences.getSystemColorThe function process.getProcessMemoryInfo has been added to get memory usage statistics about the current process.
To improve security in the remote API, new remote events have been added so that remote.getBuiltin, remote.getCurrentWindow, remote.getCurrentWebContents and <webview>.getWebContents can be filtered.
BrowserWindow now supports managing multiple BrowserViews within the same BrowserWindow.
Packaged apps will now behave the same as the default app: a default application menu will be created unless the app has one and the window-all-closed event will be automatically handled unless the app handles the event.
Mixed sandbox mode is now enabled by default. Renderers launched with sandbox: true will now be actually sandboxed, where previously they would only be sandboxed if mixed-sandbox mode was also enabled.
The default values of nodeIntegration and webviewTag are now false to improve security.
The SpellCheck API has been changed to provide asynchronous results.
The following APIs are newly deprecated in Electron 5.0.0 and planned for removal in 6.0.0:
mksnapshot 用于武器和arm64 的本机二进制二进制已废弃，将在6秒后移除。 .0 可以使用 x64 二进制程序为手臂和arm64 创建快照。
Deprecated ServiceWorker APIs on WebContents in preparation for their removal.
webContents.hasServiceWorkerwebContents.unregisterServiceWorkerIn order to improve security, the following modules are being deprecated for use directly via require and will instead need to be included via remote.require in a sandboxed webcontents:
electron.screenchild_processfsos路径webFrame.setIsolatedWorldContentSecurityPolicy,webFrame.setIsolatedWorldHumanReadableName, webFrame.setIsolatedWorldSecurityOrigin have been deprecated in favor of webFrame.setIsolatedWorldInfo.
enableMixedSandbox and the --enable-mixed-sandbox command-line switch still exist for compatibility, but are deprecated and have no effect.
Per our supported versions policy, 2.0.x has reached end of life.
We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.
在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。 尽管我们谨慎地避免对发布日期做出承诺，但我们的计划是大约每季度发布一次 Electron 的新主要版本以及这些组件的新版本。 暂定 6.0.0 时间表 展示了 Electron 6 开发生命周期中的关键日期。 Also, see our versioning document for more detailed information about versioning in Electron.
For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.
As Electron grows in popularity for desktop applications, the team working on it has also grown: we have more fulltime maintainers who work for different companies, live in different timezones, and have different interests. We're introducing a governance structure so we can keep growing smoothly.
People in the Electron project coordinate in timezones around the world with volunteers, with full-time maintainers, and with several companies who all rely on Electron. Until now, we've been successful with informal coordination; but as the team has grown, we've found that the approach doesn't scale. We also want to make it easier for new contributors to find a place to call home in the project.
Electron governance includes working groups that are responsible for different parts of the project. We're starting out with seven groups:
These groups will coordinate with each other, but each has their own meeting schedules and agendas to be productive on their own. More details on these groups are available at the governance repository.
This shouldn't have any direct effect on Electron's direction. If our strategy is successful, working groups will make it easier for new contributors to find topics that interest them, and make maintainers' lives simpler by moving discussion unrelated to their day-to-day work to other groups. If that happens, it may indirectly affect things by having more unblocked people working together.
C++或Objective-C写的Electron的功能如何被JavaScript访问，以便最终用户可以使用？
Electron 是一个JavaScript 平台，其主要目的是降低门口，让开发人员能够构建强大的桌面应用，而不必担心平台的具体实现情况。 然而，在其核心上，Electron本身仍然需要特定平台的功能以特定的系统语言写入。
In reality, Electron handles the native code for you so that you can focus on a single JavaScript API.
How does that work, though? C++或Objective-C写的Electron的功能如何被JavaScript访问，以便最终用户可以使用？
To trace this pathway, let's start with the app module.
By opening the app.ts file inside our lib/ directory, you'll find the following line of code towards the top:
const binding = process.electronBinding('app');
This line points directly to Electron's mechanism for binding its C++/Objective-C modules to JavaScript for use by developers. This function is created by the header and implementation file for the ElectronBindings class.
process.electronBindingThese files add the process.electronBinding function, which behaves like Node.js’ process.binding. process.binding is a lower-level implementation of Node.js' require() method, except it allows users to require native code instead of other code written in JS. This custom process.electronBinding function confers the ability to load native code from Electron.
When a top-level JavaScript module (like app) requires this native code, how is the state of that native code determined and set? Where are the methods exposed up to JavaScript? What about the properties?
native_mate目前，这个可以在native_mate找到答案解决方案，Chromium的一个 gin 分支库，它使得在C++和JavaScript的类型交互更加容易
Inside native_mate/native_mate there's a header and implementation file for object_template_builder. This is what allow us to form modules in native code whose shape conforms to what JavaScript developers would expect.
mate::ObjectTemplateBuilderIf we look at every Electron module as an object, it becomes easier to see why we would want to use object_template_builder to construct them. This class is built on top of a class exposed by V8, which is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++. V8 implements the JavaScript (ECMAScript) specification, so its native functionality implementations can be directly correlated to implementations in JavaScript. For example, v8::ObjectTemplate gives us JavaScript objects without a dedicated constructor function and prototype. It uses Object[.prototype], and in JavaScript would be equivalent to Object.create().
To see this in action, look to the implementation file for the app module, atom_api_app.cc. At the bottom is the following:
mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
.SetMethod("getGPUInfo", &App::GetGPUInfo)
In the above line, .SetMethod is called on mate::ObjectTemplateBuilder. .SetMethod can be called on any instance of the ObjectTemplateBuilder class to set methods on the Object prototype in JavaScript, with the following syntax:
.SetMethod("method_name", &function_to_bind)
This is the JavaScript equivalent of:
function App{}
App.prototype.getGPUInfo = function () {
// implementation here
}
This class also contains functions to set properties on a module:
.SetProperty("property_name", &getter_function_to_bind)
或
.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)
These would in turn be the JavaScript implementations of Object.defineProperty:
function App {}
Object.defineProperty(App.prototype, 'myProperty', {
get() {
return _myProperty
}
})
和
function App {}
Object.defineProperty(App.prototype, 'myProperty', {
get() {
return _myProperty
}
set(newPropertyValue) {
_myProperty = newPropertyValue
}
})
It’s possible to create JavaScript objects formed with prototypes and properties as developers expect them, and more clearly reason about functions and properties implemented at this lower system level!
The decision around where to implement any given module method is itself a complex and oft-nondeterministic one, which we'll cover in a future post.