Merge branch 'main' into main

DEPS

@@ -2,9 +2,9 @@ gclient_gn_args_from = 'src'
 
 vars = {
   'chromium_version':
-    '106.0.5216.0',
+    '107.0.5286.0',
   'node_version':
-    'v16.16.0',
+    'v16.17.0',
   'nan_version':
     '16fa32231e2ccd89d2804b3f765319128b20c4ac',
   'squirrel.mac_version':

ELECTRON_VERSION

@@ -1 +1 @@
-22.0.0-nightly.20220825
+22.0.0-nightly.20220908

appveyor.yml

@@ -225,7 +225,7 @@ for:
     on_finish:
       # Uncomment this lines to enable RDP
       #- ps: $blockRdp = $true; iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))
-      - cd ..
+      - cd C:\projects\src
       - if exist out\Default\windows_toolchain_profile.json ( appveyor-retry appveyor PushArtifact out\Default\windows_toolchain_profile.json )
       - if exist out\Default\dist.zip (appveyor-retry appveyor PushArtifact out\Default\dist.zip)
       - if exist out\Default\shell_browser_ui_unittests.exe (appveyor-retry appveyor PushArtifact out\Default\shell_browser_ui_unittests.exe)

chromium_src/BUILD.gn

@@ -156,10 +156,7 @@ static_library("chrome") {
     "//services/strings",
   ]
 
-  deps = [
-    "//chrome/browser:resource_prefetch_predictor_proto",
-    "//components/optimization_guide/proto:optimization_guide_proto",
-  ]
+  deps = [ "//chrome/browser:resource_prefetch_predictor_proto" ]
 
   if (is_linux) {
     sources += [ "//chrome/browser/icon_loader_auralinux.cc" ]
@@ -232,6 +229,8 @@ static_library("chrome") {
       "//chrome/browser/printing/printer_query.h",
       "//chrome/browser/printing/printing_service.cc",
       "//chrome/browser/printing/printing_service.h",
+      "//components/printing/browser/print_to_pdf/pdf_print_job.cc",
+      "//components/printing/browser/print_to_pdf/pdf_print_job.h",
       "//components/printing/browser/print_to_pdf/pdf_print_utils.cc",
       "//components/printing/browser/print_to_pdf/pdf_print_utils.h",
     ]
@@ -395,6 +394,10 @@ source_set("chrome_spellchecker") {
 
   if (enable_builtin_spellchecker) {
     sources += [
+      "//chrome/browser/profiles/profile_keyed_service_factory.cc",
+      "//chrome/browser/profiles/profile_keyed_service_factory.h",
+      "//chrome/browser/profiles/profile_selections.cc",
+      "//chrome/browser/profiles/profile_selections.h",
       "//chrome/browser/spellchecker/spell_check_host_chrome_impl.cc",
       "//chrome/browser/spellchecker/spell_check_host_chrome_impl.h",
       "//chrome/browser/spellchecker/spellcheck_custom_dictionary.cc",

docs/api/protocol.md

@@ -10,11 +10,12 @@ An example of implementing a protocol that has the same effect as the
 ```javascript
 const { app, protocol } = require('electron')
 const path = require('path')
+const url = require('url')
 
 app.whenReady().then(() => {
   protocol.registerFileProtocol('atom', (request, callback) => {
-    const url = request.url.substr(7)
-    callback({ path: path.normalize(`${__dirname}/${url}`) })
+    const filePath = url.fileURLToPath('file://' + request.url.slice('atom://'.length))
+    callback(filePath)
   })
 })
 ```
@@ -175,7 +176,7 @@ property.
 * `handler` Function
   * `request` [ProtocolRequest](structures/protocol-request.md)
   * `callback` Function
-    * `response` ProtocolResponse
+    * `response` [ProtocolResponse](structures/protocol-response.md)
 
 Returns `boolean` - Whether the protocol was successfully registered
 

docs/api/web-frame-main.md

@@ -169,6 +169,16 @@ convenient when `nodeIntegrationInSubFrames` is not enabled.
 
 A `string` representing the current URL of the frame.
 
+#### `frame.origin` _Readonly_
+
+A `string` representing the current origin of the frame, serialized according
+to [RFC 6454](https://www.rfc-editor.org/rfc/rfc6454). This may be different
+from the URL. For instance, if the frame is a child window opened to
+`about:blank`, then `frame.origin` will return the parent frame's origin, while
+`frame.url` will return the empty string. Pages without a scheme/host/port
+triple origin will have the serialized origin of `"null"` (that is, the string
+containing the letters n, u, l, l).
+
 #### `frame.top` _Readonly_
 
 A `WebFrameMain | null` representing top frame in the frame hierarchy to which `frame`

docs/tutorial/asar-integrity.md

@@ -0,0 +1,53 @@
+---
+title: 'ASAR Integrity'
+description: 'An experimental feature that ensures the validity of ASAR contents at runtime.'
+slug: asar-integrity
+hide_title: false
+---
+
+## Platform Support
+
+Currently ASAR integrity checking is only supported on macOS.
+
+## Requirements
+
+### Electron Forge / Electron Packager
+
+If you are using `>= electron-packager@15.4.0` or `>= @electron-forge/core@6.0.0-beta.61` then all these requirements are met for you automatically and you can skip to [Toggling the Fuse](#toggling-the-fuse).
+
+### Other build systems
+
+In order to enable ASAR integrity checking you need to ensure that your `app.asar` file was generated by a version of the `asar` npm package that supports asar integrity.  Support was introduced in version `3.1.0`.
+
+Your must then populate a valid `ElectronAsarIntegrity` dictionary block in your packaged apps `Info.plist`.  An example is included below.
+
+```plist
+<key>ElectronAsarIntegrity</key>
+<dict>
+  <key>Resources/app.asar</key>
+  <dict>
+    <key>algorithm</key>
+    <string>SHA256</string>
+    <key>hash</key>
+    <string>9d1f61ea03c4bb62b4416387a521101b81151da0cfbe18c9f8c8b818c5cebfac</string>
+  </dict>
+</dict>
+```
+
+Valid `algorithm` values are currently `SHA256` only.  The `hash` is a hash of the ASAR header using the given algorithm.  The `asar` package exposes a `getRawHeader` method whose result can then be hashed to generate this value.
+
+## Toggling the Fuse
+
+ASAR integrity checking is currently disabled by default and can be enabled by toggling a fuse. See [Electron Fuses](fuses.md) for more information on what Electron Fuses are and how they work.  When enabling this fuse you typically also want to enable the `onlyLoadAppFromAsar` fuse otherwise the validity checking can be bypassed via the Electron app code search path.
+
+```js
+require('@electron/fuses').flipFuses(
+  // E.g. /a/b/Foo.app
+  pathToPackagedApp,
+  {
+    version: FuseVersion.V1,
+    [FuseV1Options.EnableEmbeddedAsarIntegrityValidation]: true,
+    [FuseV1Options.OnlyLoadAppFromAsar]: true
+  }
+)
+```

docs/tutorial/fuses.md

@@ -8,6 +8,52 @@ For a subset of Electron functionality it makes sense to disable certain feature
 
 Fuses are the solution to this problem, at a high level they are "magic bits" in the Electron binary that can be flipped when packaging your Electron app to enable / disable certain features / restrictions.  Because they are flipped at package time before you code sign your app the OS becomes responsible for ensuring those bits aren't flipped back via OS level code signing validation (Gatekeeper / App Locker).
 
+## Current Fuses
+
+### `runAsNode`
+
+**Default:** Enabled
+**@electron/fuses:** `FuseV1Options.RunAsNode`
+
+The runAsNode fuse toggles whether the `ELECTRON_RUN_AS_NODE` environment variable is respected or not.  Please note that if this fuse is disabled then `process.fork` in the main process will not function as expected as it depends on this environment variable to function.
+
+### `cookieEncryption`
+
+**Default:** Disabled
+**@electron/fuses:** `FuseV1Options.EnableCookieEncryption`
+
+The cookieEncryption fuse toggles whether the cookie store on disk is encrypted using OS level cryptography keys.  By default the sqlite database that Chromium uses to store cookies stores the values in plaintext.  If you wish to ensure your apps cookies are encrypted in the same way Chrome does then you should enable this fuse.  Please note it is a one-way transition, if you enable this fuse existing unencrypted cookies will be encrypted-on-write but if you then disable the fuse again your cookie store will effectively be corrupt and useless.  Most apps can safely enable this fuse.
+
+### `nodeOptions`
+
+**Default:** Enabled
+**@electron/fuses:** `FuseV1Options.EnableNodeOptionsEnvironmentVariable`
+
+The nodeOptions fuse toggles whether the [`NODE_OPTIONS`](https://nodejs.org/api/cli.html#node_optionsoptions) environment variable is respected or not.  This environment variable can be used to pass all kinds of custom options to the Node.js runtime and isn't typically used by apps in production.  Most apps can safely disable this fuse.
+
+### `nodeCliInspect`
+
+**Default:** Enabled
+**@electron/fuses:** `FuseV1Options.EnableNodeCliInspectArguments`
+
+The nodeCliInspect fuse toggles whether the `--inspect`, `--inspect-brk`, etc. flags are respected or not.  When disabled it also ensures that `SIGUSR1` signal does not initialize the main process inspector.  Most apps can safely disable this fuse.
+
+### `embeddedAsarIntegrityValidation`
+
+**Default:** Disabled
+**@electron/fuses:** `FuseV1Options.EnableEmbeddedAsarIntegrityValidation`
+
+The embeddedAsarIntegrityValidation fuse toggles an experimental feature on macOS that validates the content of the `app.asar` file when it is loaded.  This feature is designed to have a minimal performance impact but may marginally slow down file reads from inside the `app.asar` archive.
+
+For more information on how to use asar integrity validation please read the [Asar Integrity](asar-integrity.md) documentation.
+
+### `onlyLoadAppFromAsar`
+
+**Default:** Disabled
+**@electron/fuses:** `FuseV1Options.OnlyLoadAppFromAsar`
+
+The onlyLoadAppFromAsar fuse changes the search system that Electron uses to locate your app code.  By default Electron will search in the following order `app.asar` -> `app` -> `default_app.asar`.  When this fuse is enabled the search order becomes a single entry `app.asar` thus ensuring that when combined with the `embeddedAsarIntegrityValidation` fuse it is impossible to load non-validated code.
+
 ## How do I flip the fuses?
 
 ### The easy way
@@ -20,11 +66,18 @@ require('@electron/fuses').flipFuses(
   require('electron'),
   // Fuses to flip
   {
-    runAsNode: false
+    version: FuseVersion.V1,
+    [FuseV1Options.RunAsNode]: false
   }
 )
 ```
 
+You can validate the fuses have been flipped or check the fuse status of an arbitrary Electron app using the fuses CLI.
+
+```bash
+ npx @electron/fuses read --app /Applications/Foo.app
+```
+
 ### The hard way
 
 #### Quick Glossary

docs/tutorial/introduction.md

@@ -47,7 +47,7 @@ are the different categories and what you can expect on each one:
 - **Examples**: Quick references to add features to your Electron app.
 - **Development**: Miscellaneous development guides.
 - **Distribution**: Learn how to distribute your app to end users.
-- **Testing and debugging**: How to debug JavaScript, write tests, and other tools used
+- **Testing And Debugging**: How to debug JavaScript, write tests, and other tools used
   to create quality Electron applications.
 - **References**: Useful links to better understand how the Electron project works
   and is organized.

docs/tutorial/sandbox.md

@@ -12,28 +12,10 @@ the GPU service and the network service.
 
 See Chromium's [Sandbox design document][sandbox] for more information.
 
-## Electron's sandboxing policies
-
-Electron comes with a mixed sandbox environment, meaning sandboxed processes can run
-alongside privileged ones. By default, renderer processes are not sandboxed, but
-utility processes are. Note that as in Chromium, the main (browser) process is
-privileged and cannot be sandboxed.
-
-Historically, this mixed sandbox approach was established because having Node.js available
-in the renderer is an extremely powerful tool for app developers. Unfortunately, this
-feature is also an equally massive security vulnerability.
-
-Theoretically, unsandboxed renderers are not a problem for desktop applications that
-only display trusted code, but they make Electron less secure than Chromium for
-displaying untrusted web content. However, even purportedly trusted code may be
-dangerous — there are countless attack vectors that malicious actors can use, from
-cross-site scripting to content injection to man-in-the-middle attacks on remotely loaded
-websites, just to name a few. For this reason, we recommend enabling renderer sandboxing
-for the vast majority of cases under an abundance of caution.
-
-<!--TODO: update this guide when #28466 is either solved or closed -->
-Note that there is an active discussion in the issue tracker to enable renderer sandboxing
-by default. See [#28466][issue-28466]) for details.
+Starting from Electron 20, the sandbox is enabled for renderer processes without any
+further configuration. If you want to disable the sandbox for a process, see the
+[Disabling the sandbox for a single process](#disabling-the-sandbox-for-a-single-process)
+section.
 
 ## Sandbox behaviour in Electron
 
@@ -46,12 +28,17 @@ When renderer processes in Electron are sandboxed, they behave in the same way a
 regular Chrome renderer would. A sandboxed renderer won't have a Node.js
 environment initialized.
 
-<!-- TODO(erickzhao): when we have a solid guide for IPC, link it here -->
 Therefore, when the sandbox is enabled, renderer processes can only perform privileged
 tasks (such as interacting with the filesystem, making changes to the system, or spawning
 subprocesses) by delegating these tasks to the main process via inter-process
 communication (IPC).
 
+:::note
+
+For more info on inter-process communication, check out our [IPC guide](./ipc.md).
+
+:::
+
 ### Preload scripts
 
 In order to allow renderer processes to communicate with the main process, preload
@@ -66,7 +53,7 @@ but can only import a subset of Electron and Node's built-in modules:
 
 In addition, the preload script also polyfills certain Node.js primitives as globals:
 
-* [`Buffer`](https://nodejs.org/api/Buffer.html)
+* [`Buffer`](https://nodejs.org/api/buffer.html)
 * [`process`](../api/process.md)
 * [`clearImmediate`](https://nodejs.org/api/timers.html#timers_clearimmediate_immediate)
 * [`setImmediate`](https://nodejs.org/api/timers.html#timers_setimmediate_callback_args)
@@ -83,13 +70,17 @@ privileged APIs to untrusted code running in the renderer process unless
 
 ## Configuring the sandbox
 
-### Enabling the sandbox for a single process
+For most apps, sandboxing is the best choice. In certain use cases that are incompatible with
+the sandbox (for instance, when using native node modules in the renderer),
+it is possible to disable the sandbox for specific processes. This comes with security
+risks, especially if any untrusted code or content is present in the unsandboxed process.
 
-In Electron, renderer sandboxing can be enabled on a per-process basis with
-the `sandbox: true` preference in the [`BrowserWindow`][browser-window] constructor.
+### Disabling the sandbox for a single process
 
-```js
-// main.js
+In Electron, renderer sandboxing can be disabled on a per-process basis with
+the `sandbox: false` preference in the [`BrowserWindow`][browser-window] constructor.
+
+```js title='main.js'
 app.whenReady().then(() => {
   const win = new BrowserWindow({
     webPreferences: {
@@ -100,17 +91,30 @@ app.whenReady().then(() => {
 })
 ```
 
+Sandboxing is also disabled whenever Node.js integration is enabled in the renderer.
+This can be done through the BrowserWindow constructor with the `nodeIntegration: true` flag.
+
+```js title='main.js'
+app.whenReady().then(() => {
+  const win = new BrowserWindow({
+    webPreferences: {
+      nodeIntegration: true
+    }
+  })
+  win.loadURL('https://google.com')
+})
+```
+
 ### Enabling the sandbox globally
 
 If you want to force sandboxing for all renderers, you can also use the
 [`app.enableSandbox`][enable-sandbox] API. Note that this API has to be called before the
 app's `ready` event.
 
-```js
-// main.js
+```js title='main.js'
 app.enableSandbox()
 app.whenReady().then(() => {
-  // no need to pass `sandbox: true` since `app.enableSandbox()` was called.
+  // any sandbox:false calls are overridden since `app.enableSandbox()` was called.
   const win = new BrowserWindow()
   win.loadURL('https://google.com')
 })
@@ -139,16 +143,16 @@ issues:
    have, to inherit everything we can from Chromium, and to respond quickly to
    security issues, but Electron cannot be as secure as Chromium without the
    resources that Chromium is able to dedicate.
-2. Some security features in Chrome (such as Safe Browsing and Certificate
+1. Some security features in Chrome (such as Safe Browsing and Certificate
    Transparency) require a centralized authority and dedicated servers, both of
    which run counter to the goals of the Electron project. As such, we disable
    those features in Electron, at the cost of the associated security they
    would otherwise bring.
-3. There is only one Chromium, whereas there are many thousands of apps built
+1. There is only one Chromium, whereas there are many thousands of apps built
    on Electron, all of which behave slightly differently. Accounting for those
    differences can yield a huge possibility space, and make it challenging to
    ensure the security of the platform in unusual use cases.
-4. We can't push security updates to users directly, so we rely on app vendors
+1. We can't push security updates to users directly, so we rely on app vendors
    to upgrade the version of Electron underlying their app in order for
    security updates to reach users.