Bump v12.0.9

* fix: adjust initial webContents focus calculation

* fix: active window check on mac

* fix: about:blank focus behavior

* chore: add spec

Co-authored-by: Raymond Zhao <raymondzhao@microsoft.com>

Co-authored-by: Raymond Zhao <raymondzhao@microsoft.com>

.circleci/config.yml

@@ -261,7 +261,7 @@ step-gclient-sync: &step-gclient-sync
           if ! git diff-index --quiet HEAD --; then
             # There are changes to the patches. Make a git commit with the updated patches
             git add patches
-            GIT_COMMITTER_NAME="Electron Bot" GIT_COMMITTER_EMAIL="electron@github.com" git commit -m "update patches" --author="Electron Bot <electron@github.com>"
+            GIT_COMMITTER_NAME="PatchUp" GIT_COMMITTER_EMAIL="73610968+patchup[bot]@users.noreply.github.com" git commit -m "chore: update patches" --author="PatchUp <73610968+patchup[bot]@users.noreply.github.com>"
             # Export it
             mkdir -p ../../patches
             git format-patch -1 --stdout --keep-subject --no-stat --full-index > ../../patches/update-patches.patch
@@ -308,9 +308,10 @@ step-setup-goma-for-build: &step-setup-goma-for-build
       npm install
       mkdir third_party
       node -e "require('./src/utils/goma.js').downloadAndPrepare({ gomaOneForAll: true })"
-      node -e "require('./src/utils/goma.js').ensure()"
+      third_party/goma/goma_ctl.py ensure_start
       echo 'export GN_GOMA_FILE='`node -e "console.log(require('./src/utils/goma.js').gnFilePath)"` >> $BASH_ENV
       echo 'export LOCAL_GOMA_DIR='`node -e "console.log(require('./src/utils/goma.js').dir)"` >> $BASH_ENV
+      echo 'export GOMA_FALLBACK_ON_AUTH_FAILURE=true' >> $BASH_ENV
       cd ..
 
 step-restore-brew-cache: &step-restore-brew-cache
@@ -447,9 +448,6 @@ step-fix-sync-on-mac: &step-fix-sync-on-mac
         # Fix Clang Install (wrong binary)
         rm -rf src/third_party/llvm-build
         python src/tools/clang/scripts/update.py
-        # Fix Framework Header Installs (symlinks not retained)
-        rm -rf src/electron/external_binaries
-        python src/electron/script/update-external-binaries.py
       fi
 
 step-install-signing-cert-on-mac: &step-install-signing-cert-on-mac
@@ -2539,15 +2537,19 @@ workflows:
     - osx-publish-x64-skip-checkout:
         requires:
           - mac-checkout
+        context: release-env
     - mas-publish-x64-skip-checkout:
         requires:
           - mac-checkout
+        context: release-env
     - osx-publish-arm64-skip-checkout:
         requires:
           - mac-checkout
+        context: release-env
     - mas-publish-arm64-skip-checkout:
         requires:
           - mac-checkout
+        context: release-env
 
   lint:
     when: << pipeline.parameters.run-lint >>

.env.example

@@ -4,4 +4,3 @@
 APPVEYOR_CLOUD_TOKEN=
 CIRCLE_TOKEN=
 ELECTRON_GITHUB_TOKEN=
-VSTS_TOKEN=

.gitignore

@@ -68,4 +68,6 @@ ts-gen
 .depshash-target
 
 # Used to accelerate builds after sync
-patches/mtime-cache.json
+patches/mtime-cache.json
+
+spec/fixtures/logo.png

BUILD.gn

@@ -337,7 +337,6 @@ source_set("electron_lib") {
     "//components/viz/service",
     "//content/public/browser",
     "//content/public/child",
-    "//content/public/common:service_names",
     "//content/public/gpu",
     "//content/public/renderer",
     "//content/public/utility",
@@ -649,6 +648,7 @@ source_set("electron_lib") {
   }
   if (enable_pdf_viewer) {
     deps += [
+      "//chrome/browser/resources/pdf:pdf_resources",
       "//components/pdf/browser",
       "//components/pdf/renderer",
       "//pdf:pdf_ppapi",
@@ -992,6 +992,9 @@ if (is_mac) {
     deps = [
       ":electron_app_framework_bundle_data",
       ":electron_app_resources",
+      ":electron_fuses",
+      "//base",
+      "//electron/buildflags",
     ]
     if (is_mas_build) {
       deps += [ ":electron_login_helper_app" ]

DEPS

@@ -14,9 +14,9 @@ gclient_gn_args = [
 
 vars = {
   'chromium_version':
-    '89.0.4348.1',
+    '89.0.4389.128',
   'node_version':
-    'v14.15.1',
+    'v14.16.0',
   'nan_version':
     '2c4ee8a32a299eada3cd6e468bbd0a473bfea96d',
   'squirrel.mac_version':

ELECTRON_VERSION

@@ -1 +1 @@
-12.0.0-beta.18
+12.0.9

README.md

@@ -6,7 +6,7 @@
 [![devDependency Status](https://david-dm.org/electron/electron/dev-status.svg)](https://david-dm.org/electron/electron?type=dev)
 [![Electron Discord Invite](https://img.shields.io/discord/745037351163527189?color=%237289DA&label=chat&logo=discord&logoColor=white)](https://discord.com/invite/electron)
 
-:memo: Available Translations: 🇨🇳 🇹🇼 🇧🇷 🇪🇸 🇰🇷 🇯🇵 🇷🇺 🇫🇷 🇹🇭 🇳🇱 🇹🇷 🇮🇩 🇺🇦 🇨🇿 🇮🇹 🇵🇱.
+:memo: Available Translations: 🇨🇳 🇧🇷 🇪🇸 🇯🇵 🇷🇺 🇫🇷 🇺🇸 🇩🇪.
 View these docs in other languages at [electron/i18n](https://github.com/electron/i18n/tree/master/content/).
 
 The Electron framework lets you write cross-platform desktop applications
@@ -29,15 +29,12 @@ The preferred method is to install Electron as a development dependency in your
 app:
 
 ```sh
-npm install electron --save-dev [--save-exact]
+npm install electron --save-dev
 ```
 
-The `--save-exact` flag is recommended for Electron prior to version 2, as it does not follow semantic
-versioning. As of version 2.0.0, Electron follows semver, so you don't need `--save-exact` flag. For info on how to manage Electron versions in your apps, see
-[Electron versioning](docs/tutorial/electron-versioning.md).
-
 For more installation options and troubleshooting tips, see
-[installation](docs/tutorial/installation.md).
+[installation](docs/tutorial/installation.md). For info on how to manage Electron versions in your apps, see
+[Electron versioning](docs/tutorial/electron-versioning.md).
 
 ## Quick start & Electron Fiddle
 

appveyor.yml

@@ -36,6 +36,7 @@ environment:
   ELECTRON_ENABLE_STACK_DUMPING: 1
   MOCHA_REPORTER: mocha-multi-reporters
   MOCHA_MULTI_REPORTERS: mocha-appveyor-reporter, tap
+  GOMA_FALLBACK_ON_AUTH_FAILURE: true
 notifications:
   - provider: Webhook
     url: https://electron-mission-control.herokuapp.com/rest/appveyor-hook

azure-pipelines-woa.yml

@@ -93,6 +93,6 @@ steps:
   condition: always()
 
 - powershell: |
-    Remove-Item -path $env:APPDATA/Electron* -Recurse
+    Remove-Item -path $env:APPDATA/Electron* -Recurse -Force -ErrorAction Ignore
   displayName: 'Delete user app data directories'
   condition: always()

build/webpack/webpack.config.base.js

@@ -163,7 +163,7 @@ if ((globalThis.process || binding.process).argv.includes("--profile-electron-in
         setImmediate: false
       },
       optimization: {
-        minimize: true,
+        minimize: env.mode === 'production',
         minimizer: [
           new TerserPlugin({
             terserOptions: {

build/webpack/webpack.gni

@@ -22,6 +22,11 @@ template("webpack_build") {
                "//electron/typings/internal-electron.d.ts",
              ] + invoker.inputs
 
+    mode = "development"
+    if (is_official_build) {
+      mode = "production"
+    }
+
     args = [
       "--config",
       rebase_path(invoker.config_file),
@@ -29,6 +34,7 @@ template("webpack_build") {
       "--output-path=" + rebase_path(get_path_info(invoker.out_file, "dir")),
       "--env.buildflags=" +
           rebase_path("$target_gen_dir/buildflags/buildflags.h"),
+      "--env.mode=" + mode,
     ]
     deps += [ "buildflags" ]
 

chromium_src/BUILD.gn

@@ -217,8 +217,6 @@ static_library("chrome") {
       "//chrome/browser/printing/print_view_manager_basic.h",
       "//chrome/browser/printing/printer_query.cc",
       "//chrome/browser/printing/printer_query.h",
-      "//chrome/browser/printing/printing_message_filter.cc",
-      "//chrome/browser/printing/printing_message_filter.h",
       "//chrome/browser/printing/printing_service.cc",
       "//chrome/browser/printing/printing_service.h",
     ]

default_app/default_app.ts

@@ -41,14 +41,14 @@ ipcMain.handle('bootstrap', (event) => {
   return isTrustedSender(event.sender) ? electronPath : null;
 });
 
-async function createWindow () {
+async function createWindow (backgroundColor?: string) {
   await app.whenReady();
 
   const options: Electron.BrowserWindowConstructorOptions = {
     width: 960,
     height: 620,
     autoHideMenuBar: true,
-    backgroundColor: '#2f3241',
+    backgroundColor,
     webPreferences: {
       preload: path.resolve(__dirname, 'preload.js'),
       contextIsolation: true,
@@ -96,7 +96,7 @@ export const loadURL = async (appUrl: string) => {
 };
 
 export const loadFile = async (appPath: string) => {
-  mainWindow = await createWindow();
+  mainWindow = await createWindow(appPath === 'index.html' ? '#2f3241' : undefined);
   mainWindow.loadFile(appPath);
   mainWindow.focus();
 };

docs/README.md

@@ -59,6 +59,7 @@ an issue:
   * [Using Native Node.js Modules](tutorial/using-native-node-modules.md)
   * [Performance Strategies](tutorial/performance.md)
   * [Security Strategies](tutorial/security.md)
+  * [Process Sandboxing](tutorial/sandbox.md)
 * [Accessibility](tutorial/accessibility.md)
   * [Manually Enabling Accessibility Features](tutorial/accessibility.md#manually-enabling-accessibility-features)
 * [Testing and Debugging](tutorial/application-debugging.md)
@@ -68,6 +69,7 @@ an issue:
   * [Testing on Headless CI Systems (Travis, Jenkins)](tutorial/testing-on-headless-ci.md)
   * [DevTools Extension](tutorial/devtools-extension.md)
   * [Automated Testing with a Custom Driver](tutorial/automated-testing-with-a-custom-driver.md)
+  * [REPL](tutorial/repl.md)
 * [Distribution](tutorial/application-distribution.md)
   * [Supported Platforms](tutorial/support.md#supported-platforms)
   * [Code Signing](tutorial/code-signing.md)
@@ -91,11 +93,6 @@ These individual tutorials expand on topics discussed in the guide above.
 * Electron Releases & Developer Feedback
   * [Versioning Policy](tutorial/electron-versioning.md)
   * [Release Timelines](tutorial/electron-timelines.md)
-* [Packaging App Source Code with asar](tutorial/application-packaging.md)
-  * [Generating asar Archives](tutorial/application-packaging.md#generating-asar-archives)
-  * [Using asar Archives](tutorial/application-packaging.md#using-asar-archives)
-  * [Limitations](tutorial/application-packaging.md#limitations-of-the-node-api)
-  * [Adding Unpacked Files to asar Archives](tutorial/application-packaging.md#adding-unpacked-files-to-asar-archives)
 * [Testing Widevine CDM](tutorial/testing-widevine-cdm.md)
 
 ---
@@ -131,6 +128,8 @@ These individual tutorials expand on topics discussed in the guide above.
 * [ipcMain](api/ipc-main.md)
 * [Menu](api/menu.md)
 * [MenuItem](api/menu-item.md)
+* [MessageChannelMain](api/message-channel-main.md)
+* [MessagePortMain](api/message-port-main.md)
 * [net](api/net.md)
 * [netLog](api/net-log.md)
 * [nativeTheme](api/native-theme.md)
@@ -140,6 +139,7 @@ These individual tutorials expand on topics discussed in the guide above.
 * [protocol](api/protocol.md)
 * [screen](api/screen.md)
 * [session](api/session.md)
+* [ShareMenu](api/share-menu.md)
 * [systemPreferences](api/system-preferences.md)
 * [TouchBar](api/touch-bar.md)
 * [Tray](api/tray.md)
@@ -148,15 +148,15 @@ These individual tutorials expand on topics discussed in the guide above.
 
 ### Modules for the Renderer Process (Web Page):
 
-* [desktopCapturer](api/desktop-capturer.md)
+* [contextBridge](api/context-bridge.md)
 * [ipcRenderer](api/ipc-renderer.md)
-* [remote](api/remote.md)
 * [webFrame](api/web-frame.md)
 
 ### Modules for Both Processes:
 
 * [clipboard](api/clipboard.md)
 * [crashReporter](api/crash-reporter.md)
+* [desktopCapturer](api/desktop-capturer.md)
 * [nativeImage](api/native-image.md)
 * [shell](api/shell.md)
 

docs/api/accelerator.md

@@ -35,7 +35,7 @@ Linux and Windows to define some accelerators.
 Use `Alt` instead of `Option`. The `Option` key only exists on macOS, whereas
 the `Alt` key is available on all platforms.
 
-The `Super` key is mapped to the `Windows` key on Windows and Linux and
+The `Super` (or `Meta`) key is mapped to the `Windows` key on Windows and Linux and
 `Cmd` on macOS.
 
 ## Available modifiers
@@ -48,6 +48,7 @@ The `Super` key is mapped to the `Windows` key on Windows and Linux and
 * `AltGr`
 * `Shift`
 * `Super`
+* `Meta`
 
 ## Available key codes
 

docs/api/app.md

@@ -391,7 +391,7 @@ which contains more information about why the render process disappeared. It
 isn't always because it crashed.  The `killed` boolean can be replaced by
 checking `reason === 'killed'` when you switch to that event.
 
-#### Event: 'render-process-gone'
+### Event: 'render-process-gone'
 
 Returns:
 
@@ -406,11 +406,14 @@ Returns:
     * `oom` - Process ran out of memory
     * `launch-failed` - Process never successfully launched
     * `integrity-failure` - Windows code integrity checks failed
+  * `exitCode` Integer - The exit code of the process, unless `reason` is
+    `launch-failed`, in which case `exitCode` will be a platform-specific
+    launch failure error code.
 
 Emitted when the renderer process unexpectedly disappears.  This is normally
 because it was crashed or killed.
 
-#### Event: 'child-process-gone'
+### Event: 'child-process-gone'
 
 Returns:
 
@@ -750,7 +753,8 @@ Overrides the current application's name.
 
 ### `app.getLocale()`
 
-Returns `String` - The current application locale. Possible return values are documented [here](locales.md).
+Returns `String` - The current application locale, fetched using Chromium's `l10n_util` library.
+Possible return values are documented [here](https://source.chromium.org/chromium/chromium/src/+/master:ui/base/l10n/l10n_util.cc).
 
 To set the locale, you'll want to use a command line switch at app startup, which may be found [here](https://github.com/electron/electron/blob/master/docs/api/command-line-switches.md).
 
@@ -926,6 +930,10 @@ re-add a removed item to a custom category earlier than that will result in the
 entire custom category being omitted from the Jump List. The list of removed
 items can be obtained using `app.getJumpListSettings()`.
 
+**Note:** The maximum length of a Jump List item's `description` property is
+260 characters. Beyond this limit, the item will not be added to the Jump
+List, nor will it be displayed.
+
 Here's a very simple example of creating a custom Jump List:
 
 ```javascript

docs/api/browser-view.md

@@ -1,14 +1,16 @@
-## Class: BrowserView
-
-> Create and control views.
-
-Process: [Main](../glossary.md#main-process)
+# BrowserView
 
 A `BrowserView` can be used to embed additional web content into a
 [`BrowserWindow`](browser-window.md). It is like a child window, except that it is positioned
 relative to its owning window. It is meant to be an alternative to the
 `webview` tag.
 
+## Class: BrowserView
+
+> Create and control views.
+
+Process: [Main](../glossary.md#main-process)
+
 ### Example
 
 ```javascript

docs/api/browser-window.md

@@ -265,12 +265,12 @@ It creates a new `BrowserWindow` with native properties as set by the `options`.
       be the absolute file path to the script.
       When node integration is turned off, the preload script can reintroduce
       Node global symbols back to the global scope. See example
-      [here](process.md#event-loaded).
+      [here](context-bridge.md#exposing-node-global-symbols).
     * `sandbox` Boolean (optional) - If set, this will sandbox the renderer
       associated with the window, making it compatible with the Chromium
       OS-level sandbox and disabling the Node.js engine. This is not the same as
       the `nodeIntegration` option and the APIs available to the preload script
-      are more limited. Read more about the option [here](sandbox-option.md).
+      are more limited. Read more about the option [here](../tutorial/sandbox.md).
     * `enableRemoteModule` Boolean (optional) - Whether to enable the [`remote`](remote.md) module.
       Default is `false`.
     * `session` [Session](session.md#class-session) (optional) - Sets the session used by the
@@ -337,7 +337,7 @@ It creates a new `BrowserWindow` with native properties as set by the `options`.
       more details.
     * `contextIsolation` Boolean (optional) - Whether to run Electron APIs and
       the specified `preload` script in a separate JavaScript context. Defaults
-      to `false`. The context that the `preload` script runs in will only have
+      to `true`. The context that the `preload` script runs in will only have
       access to its own dedicated `document` and `window` globals, as well as
       its own set of JavaScript builtins (`Array`, `Object`, `JSON`, etc.),
       which are all invisible to the loaded content. The Electron API will only
@@ -349,8 +349,7 @@ It creates a new `BrowserWindow` with native properties as set by the `options`.
       context in the dev tools by selecting the 'Electron Isolated Context'
       entry in the combo box at the top of the Console tab.
     * `worldSafeExecuteJavaScript` Boolean (optional) - If true, values returned from `webFrame.executeJavaScript` will be sanitized to ensure JS values
-      can't unsafely cross between worlds when using `contextIsolation`.  The default
-      is `false`. In Electron 12, the default will be changed to `true`. _Deprecated_
+      can't unsafely cross between worlds when using `contextIsolation`. Defaults to `true`. _Deprecated_
     * `nativeWindowOpen` Boolean (optional) - Whether to use native
       `window.open()`. Defaults to `false`. Child windows will always have node
       integration disabled unless `nodeIntegrationInSubFrames` is true. **Note:** This option is currently
@@ -735,7 +734,7 @@ The method will also not return if the extension's manifest is missing or incomp
 is emitted.
 
 **Note:** This method is deprecated. Instead, use
-[`ses.loadExtension(path)`](session.md#sesloadextensionpath).
+[`ses.loadExtension(path)`](session.md#sesloadextensionpath-options).
 
 #### `BrowserWindow.removeExtension(name)` _Deprecated_
 
@@ -777,7 +776,7 @@ The method will also not return if the extension's manifest is missing or incomp
 is emitted.
 
 **Note:** This method is deprecated. Instead, use
-[`ses.loadExtension(path)`](session.md#sesloadextensionpath).
+[`ses.loadExtension(path)`](session.md#sesloadextensionpath-options).
 
 #### `BrowserWindow.removeDevToolsExtension(name)` _Deprecated_
 
@@ -1387,7 +1386,7 @@ can be be used to listen to changes to tablet mode.
 
 #### `win.getMediaSourceId()`
 
-Returns `String` - Window id in the format of DesktopCapturerSource's id. For example "window:1234:0".
+Returns `String` - Window id in the format of DesktopCapturerSource's id. For example "window:1324:0".
 
 More precisely the format is `window:id:other_id` where `id` is `HWND` on
 Windows, `CGWindowID` (`uint64_t`) on macOS and `Window` (`unsigned long`) on
@@ -1405,6 +1404,8 @@ The native type of the handle is `HWND` on Windows, `NSView*` on macOS, and
 
 * `message` Integer
 * `callback` Function
+  * `wParam` any - The `wParam` provided to the WndProc
+  * `lParam` any - The `lParam` provided to the WndProc
 
 Hooks a windows message. The `callback` is called when
 the message is received in the WndProc.
@@ -1457,7 +1458,7 @@ Returns `Boolean` - Whether the window's document has been edited.
 
 Returns `Promise<NativeImage>` - Resolves with a [NativeImage](native-image.md)
 
-Captures a snapshot of the page within `rect`. Omitting `rect` will capture the whole visible page.
+Captures a snapshot of the page within `rect`. Omitting `rect` will capture the whole visible page. If the page is not visible, `rect` may be empty.
 
 #### `win.loadURL(url[, options])`
 
@@ -1867,6 +1868,13 @@ Replacement API for setBrowserView supporting work with multi browser views.
 
 * `browserView` [BrowserView](browser-view.md)
 
+#### `win.setTopBrowserView(browserView)` _Experimental_
+
+* `browserView` [BrowserView](browser-view.md)
+
+Raises `browserView` above other `BrowserView`s attached to `win`.
+Throws an error if `browserView` is not attached to `win`.
+
 #### `win.getBrowserViews()` _Experimental_
 
 Returns `BrowserView[]` - an array of all BrowserViews that have been attached

docs/api/command-line-switches.md

@@ -80,6 +80,12 @@ This switch can not be used in `app.commandLine.appendSwitch` since it is parsed
 earlier than user's app is loaded, but you can set the `ELECTRON_ENABLE_LOGGING`
 environment variable to achieve the same effect.
 
+### --force-fieldtrials=`trials`
+
+Field trials to be forcefully enabled or disabled.
+
+For example: `WebRTC-Audio-Red-For-Opus/Enabled/`
+
 ### --host-rules=`rules`
 
 A comma-separated list of `rules` that control how hostnames are mapped.
@@ -136,7 +142,8 @@ proxy server flags that are passed.
 
 ### --no-sandbox
 
-Disables Chromium sandbox, which is now enabled by default.
+Disables the Chromium [sandbox](https://www.chromium.org/developers/design-documents/sandbox).
+Forces renderer process and Chromium helper processes to run un-sandboxed.
 Should only be used for testing.
 
 ### --proxy-bypass-list=`hosts`

docs/api/context-bridge.md

@@ -33,7 +33,7 @@ page you load in your renderer executes code in this world.
 
 ### Isolated World
 
-When `contextIsolation` is enabled in your `webPreferences`, your `preload` scripts run in an
+When `contextIsolation` is enabled in your `webPreferences` (this is the default behavior since Electron 12.0.0), your `preload` scripts run in an
 "Isolated World".  You can read more about context isolation and what it affects in the
 [security](../tutorial/security.md#3-enable-context-isolation-for-remote-content) docs.
 
@@ -109,3 +109,22 @@ has been included below for completeness:
 | `Symbol` | N/A | ❌ | ❌ | Symbols cannot be copied across contexts so they are dropped |
 
 If the type you care about is not in the above table, it is probably not supported.
+
+### Exposing Node Global Symbols
+
+The `contextBridge` can be used by the preload script to give your renderer access to Node APIs.
+The table of supported types described above also applies to Node APIs that you expose through `contextBridge`.
+Please note that many Node APIs grant access to local system resources.
+Be very cautious about which globals and APIs you expose to untrusted remote content.
+
+```javascript
+const { contextBridge } = require('electron')
+const crypto = require('crypto')
+contextBridge.exposeInMainWorld('nodeCrypto', {
+  sha256sum (data) {
+    const hash = crypto.createHash('sha256')
+    hash.update(data)
+    return hash.digest('hex')
+  }
+})
+```

docs/api/cookies.md

@@ -45,6 +45,8 @@ The following events are available on instances of `Cookies`:
 
 #### Event: 'changed'
 
+Returns:
+
 * `event` Event
 * `cookie` [Cookie](structures/cookie.md) - The cookie that was changed.
 * `cause` String - The cause of the change with one of the following values:

docs/api/dialog.md

@@ -154,7 +154,7 @@ dialog.showOpenDialog(mainWindow, {
 
 * `browserWindow` [BrowserWindow](browser-window.md) (optional)
 * `options` Object
-  * `title` String (optional)
+  * `title` String (optional) - The dialog title. Cannot be displayed on some _Linux_ desktop environments.
   * `defaultPath` String (optional) - Absolute directory path, absolute file
     path, or file name to use by default.
   * `buttonLabel` String (optional) - Custom label for the confirmation button, when
@@ -185,7 +185,7 @@ The `filters` specifies an array of file types that can be displayed, see
 
 * `browserWindow` [BrowserWindow](browser-window.md) (optional)
 * `options` Object
-  * `title` String (optional)
+  * `title` String (optional) - The dialog title. Cannot be displayed on some _Linux_ desktop environments.
   * `defaultPath` String (optional) - Absolute directory path, absolute file
     path, or file name to use by default.
   * `buttonLabel` String (optional) - Custom label for the confirmation button, when

docs/api/extensions.md

@@ -15,7 +15,7 @@ extension capabilities.
 
 Electron only supports loading unpacked extensions (i.e., `.crx` files do not
 work). Extensions are installed per-`session`. To load an extension, call
-[`ses.loadExtension`](session.md#sesloadextensionpath):
+[`ses.loadExtension`](session.md#sesloadextensionpath-options):
 
 ```js
 const { session } = require('electron')

docs/api/frameless-window.md

@@ -82,8 +82,11 @@ win.show()
 * The `blur` filter only applies to the web page, so there is no way to apply
   blur effect to the content below the window (i.e. other applications open on
   the user's system).
-* On Windows operating systems, transparent windows will not work when DWM is
+* The window will not be transparent when DevTools is opened.
+* On Windows operating systems,
+  * transparent windows will not work when DWM is
   disabled.
+  * transparent windows can not be maximized using the Windows system menu or by double clicking the title bar. The reasoning behind this can be seen on [this pull request](https://github.com/electron/electron/pull/28207).
 * On Linux, users have to put `--enable-transparent-visuals --disable-gpu` in
   the command line to disable GPU and allow ARGB to make transparent window,
   this is caused by an upstream bug that [alpha channel doesn't work on some

docs/api/ipc-renderer.md

@@ -62,10 +62,9 @@ included. Sending Functions, Promises, Symbols, WeakMaps, or WeakSets will
 throw an exception.
 
 > **NOTE:** Sending non-standard JavaScript types such as DOM objects or
-> special Electron objects is deprecated, and will begin throwing an exception
-> starting with Electron 9.
-
-> **NOTE:** Since the main process does not have support for DOM objects such as
+> special Electron objects will throw an exception.
+>
+> Since the main process does not have support for DOM objects such as
 > `ImageBitmap`, `File`, `DOMMatrix` and so on, such objects cannot be sent over
 > Electron's IPC to the main process, as the main process would have no way to decode
 > them. Attempting to send such objects over IPC will result in an error.
@@ -90,11 +89,10 @@ Algorithm][SCA], just like [`window.postMessage`][], so prototype chains will no
 included. Sending Functions, Promises, Symbols, WeakMaps, or WeakSets will
 throw an exception.
 
-> **NOTE**: Sending non-standard JavaScript types such as DOM objects or
-> special Electron objects is deprecated, and will begin throwing an exception
-> starting with Electron 9.
-
-> **NOTE:** Since the main process does not have support for DOM objects such as
+> **NOTE:** Sending non-standard JavaScript types such as DOM objects or
+> special Electron objects will throw an exception.
+>
+> Since the main process does not have support for DOM objects such as
 > `ImageBitmap`, `File`, `DOMMatrix` and so on, such objects cannot be sent over
 > Electron's IPC to the main process, as the main process would have no way to decode
 > them. Attempting to send such objects over IPC will result in an error.
@@ -134,11 +132,10 @@ Algorithm][SCA], just like [`window.postMessage`][], so prototype chains will no
 included. Sending Functions, Promises, Symbols, WeakMaps, or WeakSets will
 throw an exception.
 
-> **NOTE**: Sending non-standard JavaScript types such as DOM objects or
-> special Electron objects is deprecated, and will begin throwing an exception
-> starting with Electron 9.
-
-> **NOTE:** Since the main process does not have support for DOM objects such as
+> **NOTE:** Sending non-standard JavaScript types such as DOM objects or
+> special Electron objects will throw an exception.
+>
+> Since the main process does not have support for DOM objects such as
 > `ImageBitmap`, `File`, `DOMMatrix` and so on, such objects cannot be sent over
 > Electron's IPC to the main process, as the main process would have no way to decode
 > them. Attempting to send such objects over IPC will result in an error.

docs/api/locales.md

@@ -1,142 +0,0 @@
-# Locales
-
-> Locale values returned by `app.getLocale()`.
-
-Electron uses Chromium's `l10n_util` library to fetch the locale. Possible
-values are listed below:
-
-| Language Code | Language Name |
-|---------------|---------------|
-| af | Afrikaans |
-| am | Amharic |
-| ar | Arabic |
-| az | Azerbaijani |
-| be | Belarusian |
-| bg | Bulgarian |
-| bh | Bihari |
-| bn | Bengali |
-| br | Breton |
-| bs | Bosnian |
-| ca | Catalan |
-| co | Corsican |
-| cs | Czech |
-| cy | Welsh |
-| da | Danish |
-| de | German |
-| de-AT | German (Austria) |
-| de-CH | German (Switzerland) |
-| de-DE | German (Germany) |
-| el | Greek |
-| en | English |
-| en-AU | English (Australia) |
-| en-CA | English (Canada) |
-| en-GB | English (UK) |
-| en-NZ | English (New Zealand) |
-| en-US | English (US) |
-| en-ZA | English (South Africa) |
-| eo | Esperanto |
-| es | Spanish |
-| es-419 | Spanish (Latin America) |
-| et | Estonian |
-| eu | Basque |
-| fa | Persian |
-| fi | Finnish |
-| fil | Filipino |
-| fo | Faroese |
-| fr | French |
-| fr-CA | French (Canada) |
-| fr-CH | French (Switzerland) |
-| fr-FR | French (France) |
-| fy | Frisian |
-| ga | Irish |
-| gd | Scots Gaelic |
-| gl | Galician |
-| gn | Guarani |
-| gu | Gujarati |
-| ha | Hausa |
-| haw | Hawaiian |
-| he | Hebrew |
-| hi | Hindi |
-| hr | Croatian |
-| hu | Hungarian |
-| hy | Armenian |
-| ia | Interlingua |
-| id | Indonesian |
-| is | Icelandic |
-| it | Italian |
-| it-CH | Italian (Switzerland) |
-| it-IT | Italian (Italy) |
-| ja | Japanese |
-| jw | Javanese |
-| ka | Georgian |
-| kk | Kazakh |
-| km | Cambodian |
-| kn | Kannada |
-| ko | Korean |
-| ku | Kurdish |
-| ky | Kyrgyz |
-| la | Latin |
-| ln | Lingala |
-| lo | Laothian |
-| lt | Lithuanian |
-| lv | Latvian |
-| mk | Macedonian |
-| ml | Malayalam |
-| mn | Mongolian |
-| mo | Moldavian |
-| mr | Marathi |
-| ms | Malay |
-| mt | Maltese |
-| nb | Norwegian (Bokmal) |
-| ne | Nepali |
-| nl | Dutch |
-| nn | Norwegian (Nynorsk) |
-| no | Norwegian |
-| oc | Occitan |
-| om | Oromo |
-| or | Oriya |
-| pa | Punjabi |
-| pl | Polish |
-| ps | Pashto |
-| pt | Portuguese |
-| pt-BR | Portuguese (Brazil) |
-| pt-PT | Portuguese (Portugal) |
-| qu | Quechua |
-| rm | Romansh |
-| ro | Romanian |
-| ru | Russian |
-| sd | Sindhi |
-| sh | Serbo-Croatian |
-| si | Sinhalese |
-| sk | Slovak |
-| sl | Slovenian |
-| sn | Shona |
-| so | Somali |
-| sq | Albanian |
-| sr | Serbian |
-| st | Sesotho |
-| su | Sundanese |
-| sv | Swedish |
-| sw | Swahili |
-| ta | Tamil |
-| te | Telugu |
-| tg | Tajik |
-| th | Thai |
-| ti | Tigrinya |
-| tk | Turkmen |
-| to | Tonga |
-| tr | Turkish |
-| tt | Tatar |
-| tw | Twi |
-| ug | Uighur |
-| uk | Ukrainian |
-| ur | Urdu |
-| uz | Uzbek |
-| vi | Vietnamese |
-| xh | Xhosa |
-| yi | Yiddish |
-| yo | Yoruba |
-| zh | Chinese |
-| zh-CN | Chinese (Simplified) |
-| zh-TW | Chinese (Traditional) |
-| zu | Zulu |

docs/api/menu.md

@@ -1,3 +1,5 @@
+# Menu
+
 ## Class: Menu
 
 > Create native application menus and context menus.

docs/api/message-channel-main.md

@@ -9,12 +9,15 @@ channel messaging.
 
 ## Class: MessageChannelMain
 
+> Channel interface for channel messaging in the main process.
+
 Process: [Main](../glossary.md#main-process)
 
 Example:
 
 ```js
 // Main process
+const { MessageChannelMain } = require('electron')
 const { port1, port2 } = new MessageChannelMain()
 w.webContents.postMessage('port', null, [port2])
 port1.postMessage({ some: 'message' })

docs/api/message-port-main.md

@@ -14,6 +14,8 @@ channel messaging.
 
 ## Class: MessagePortMain
 
+> Port interface for channel messaging in the main process.
+
 Process: [Main](../glossary.md#main-process)
 
 ### Instance Methods

docs/api/modernization/overview.md

@@ -1,10 +0,0 @@
-## Modernization
-
-The Electron team is currently undergoing an initiative to modernize our API in a few concrete ways. These include: updating our modules to use idiomatic JS properties instead of separate `getPropertyX` and `setPropertyX`, converting callbacks to promises, and removing some other anti-patterns present in our APIs. The current status of the Promise initiative can be tracked in the [promisification](promisification.md) tracking file.
-
-As we work to perform these updates, we seek to create the least disruptive amount of change at any given time, so as many changes as possible will be introduced in a backward compatible manner and deprecated after enough time has passed to give users a chance to upgrade their API calls.
-
-This document and its child documents will be updated to reflect the latest status of our API changes.
-
-* [Promisification](promisification.md)
-* [Property Updates](property-updates.md)

docs/api/modernization/promisification.md

@@ -1,42 +0,0 @@
-## Promisification
-
-The Electron team recently underwent an initiative to convert callback-based APIs to Promise-based ones. See converted functions below:
-
-- [app.getFileIcon(path[, options], callback)](https://github.com/electron/electron/blob/master/docs/api/app.md#getFileIcon)
-- [contents.capturePage([rect, ]callback)](https://github.com/electron/electron/blob/master/docs/api/web-contents.md#capturePage)
-- [contents.executeJavaScript(code[, userGesture, callback])](https://github.com/electron/electron/blob/master/docs/api/web-contents.md#executeJavaScript)
-- [contents.printToPDF(options, callback)](https://github.com/electron/electron/blob/master/docs/api/web-contents.md#printToPDF)
-- [contents.savePage(fullPath, saveType, callback)](https://github.com/electron/electron/blob/master/docs/api/web-contents.md#savePage)
-- [contentTracing.getCategories(callback)](https://github.com/electron/electron/blob/master/docs/api/content-tracing.md#getCategories)
-- [contentTracing.startRecording(options, callback)](https://github.com/electron/electron/blob/master/docs/api/content-tracing.md#startRecording)
-- [contentTracing.stopRecording(resultFilePath, callback)](https://github.com/electron/electron/blob/master/docs/api/content-tracing.md#stopRecording)
-- [contentTracing.getTraceBufferUsage(callback)](https://github.com/electron/electron/blob/master/docs/api/content-tracing.md#getTraceBufferUsage)
-- [cookies.flushStore(callback)](https://github.com/electron/electron/blob/master/docs/api/cookies.md#flushStore)
-- [cookies.get(filter, callback)](https://github.com/electron/electron/blob/master/docs/api/cookies.md#get)
-- [cookies.remove(url, name, callback)](https://github.com/electron/electron/blob/master/docs/api/cookies.md#remove)
-- [cookies.set(details, callback)](https://github.com/electron/electron/blob/master/docs/api/cookies.md#set)
-- [debugger.sendCommand(method[, commandParams, callback])](https://github.com/electron/electron/blob/master/docs/api/debugger.md#sendCommand)
-- [desktopCapturer.getSources(options, callback)](https://github.com/electron/electron/blob/master/docs/api/desktop-capturer.md#getSources)
-- [dialog.showOpenDialog([browserWindow, ]options[, callback])](https://github.com/electron/electron/blob/master/docs/api/dialog.md#showOpenDialog)
-- [dialog.showSaveDialog([browserWindow, ]options[, callback])](https://github.com/electron/electron/blob/master/docs/api/dialog.md#showSaveDialog)
-- [inAppPurchase.purchaseProduct(productID, quantity, callback)](https://github.com/electron/electron/blob/master/docs/api/in-app-purchase.md#purchaseProduct)
-- [inAppPurchase.getProducts(productIDs, callback)](https://github.com/electron/electron/blob/master/docs/api/in-app-purchase.md#getProducts)
-- [dialog.showMessageBox([browserWindow, ]options[, callback])](https://github.com/electron/electron/blob/master/docs/api/dialog.md#showMessageBox)
-- [dialog.showCertificateTrustDialog([browserWindow, ]options, callback)](https://github.com/electron/electron/blob/master/docs/api/dialog.md#showCertificateTrustDialog)
-- [netLog.stopLogging([callback])](https://github.com/electron/electron/blob/master/docs/api/net-log.md#stopLogging)
-- [protocol.isProtocolHandled(scheme, callback)](https://github.com/electron/electron/blob/master/docs/api/protocol.md#isProtocolHandled)
-- [ses.clearHostResolverCache([callback])](https://github.com/electron/electron/blob/master/docs/api/session.md#clearHostResolverCache)
-- [ses.clearStorageData([options, callback])](https://github.com/electron/electron/blob/master/docs/api/session.md#clearStorageData)
-- [ses.setProxy(config, callback)](https://github.com/electron/electron/blob/master/docs/api/session.md#setProxy)
-- [ses.resolveProxy(url, callback)](https://github.com/electron/electron/blob/master/docs/api/session.md#resolveProxy)
-- [ses.getCacheSize(callback)](https://github.com/electron/electron/blob/master/docs/api/session.md#getCacheSize)
-- [ses.clearAuthCache(options[, callback])](https://github.com/electron/electron/blob/master/docs/api/session.md#clearAuthCache)
-- [ses.clearCache(callback)](https://github.com/electron/electron/blob/master/docs/api/session.md#clearCache)
-- [ses.getBlobData(identifier, callback)](https://github.com/electron/electron/blob/master/docs/api/session.md#getBlobData)
-- [shell.openExternal(url[, options, callback])](https://github.com/electron/electron/blob/master/docs/api/shell.md#openExternal)
-- [webFrame.executeJavaScript(code[, userGesture, callback])](https://github.com/electron/electron/blob/master/docs/api/web-frame.md#executeJavaScript)
-- [webFrame.executeJavaScriptInIsolatedWorld(worldId, scripts[, userGesture, callback])](https://github.com/electron/electron/blob/master/docs/api/web-frame.md#executeJavaScriptInIsolatedWorld)
-- [webviewTag.capturePage([rect, ]callback)](https://github.com/electron/electron/blob/master/docs/api/webview-tag.md#capturePage)
-- [webviewTag.executeJavaScript(code[, userGesture, callback])](https://github.com/electron/electron/blob/master/docs/api/webview-tag.md#executeJavaScript)
-- [webviewTag.printToPDF(options, callback)](https://github.com/electron/electron/blob/master/docs/api/webview-tag.md#printToPDF)
-- [win.capturePage([rect, ]callback)](https://github.com/electron/electron/blob/master/docs/api/browser-window.md#capturePage)

docs/api/modernization/property-updates.md

@@ -1,41 +0,0 @@
-## Property Updates
-
-The Electron team is currently undergoing an initiative to convert separate getter and setter functions in Electron to bespoke properties with `get` and `set` functionality. During this transition period, both the new properties and old getters and setters of these functions will work correctly and be documented.
-
-## Candidates
-
-* `BrowserWindow`
-  * `menubarVisible`
-* `crashReporter` module
-  * `uploadToServer`
-* `webFrame` modules
-  * `zoomFactor`
-  * `zoomLevel`
-  * `audioMuted`
-* `<webview>`
-  * `zoomFactor`
-  * `zoomLevel`
-  * `audioMuted`
-
-## Converted Properties
-
-* `app` module
-  * `accessibilitySupport`
-  * `applicationMenu`
-  * `badgeCount`
-  * `name`
-* `DownloadItem` class
-  * `savePath`
-* `BrowserWindow` module
-  * `autoHideMenuBar`
-  * `resizable`
-  * `maximizable`
-  * `minimizable`
-  * `fullscreenable`
-  * `movable`
-  * `closable`
-  * `backgroundThrottling`
-* `NativeImage`
-  * `isMacTemplateImage`
-* `SystemPreferences` module
-  * `appLevelAppearance`

docs/api/process.md

@@ -42,19 +42,6 @@ In sandboxed renderers the `process` object contains only a subset of the APIs:
 Emitted when Electron has loaded its internal initialization script and is
 beginning to load the web page or the main script.
 
-It can be used by the preload script to add removed Node global symbols back to
-the global scope when node integration is turned off:
-
-```javascript
-// preload.js
-const _setImmediate = setImmediate
-const _clearImmediate = clearImmediate
-process.once('loaded', () => {
-  global.setImmediate = _setImmediate
-  global.clearImmediate = _clearImmediate
-})
-```
-
 ## Properties
 
 ### `process.defaultApp` _Readonly_

docs/api/sandbox-option.md

@@ -1,182 +0,0 @@
-# `sandbox` Option
-
-> Create a browser window with a sandboxed renderer. With this
-option enabled, the renderer must communicate via IPC to the main process in order to access node APIs.
-
-One of the key security features of Chromium is that all blink rendering/JavaScript
-code is executed within a sandbox. This sandbox uses OS-specific features to ensure
-that exploits in the renderer process cannot harm the system.
-
-In other words, when the sandbox is enabled, the renderers can only make changes
-to the system by delegating tasks to the main process via IPC.
-[Here's](https://www.chromium.org/developers/design-documents/sandbox) more
-information about the sandbox.
-
-Since a major feature in Electron is the ability to run Node.js in the
-renderer process (making it easier to develop desktop applications using web
-technologies), the sandbox is disabled by electron. This is because
-most Node.js APIs require system access. `require()` for example, is not
-possible without file system permissions, which are not available in a sandboxed
-environment.
-
-Usually this is not a problem for desktop applications since the code is always
-trusted, but it makes Electron less secure than Chromium for displaying
-untrusted web content. For applications that require more security, the
-`sandbox` flag will force Electron to spawn a classic Chromium renderer that is
-compatible with the sandbox.
-
-A sandboxed renderer doesn't have a Node.js environment running and doesn't
-expose Node.js JavaScript APIs to client code. The only exception is the preload script,
-which has access to a subset of the Electron renderer API.
-
-Another difference is that sandboxed renderers don't modify any of the default
-JavaScript APIs. Consequently, some APIs such as `window.open` will work as they
-do in Chromium (i.e. they do not return a [`BrowserWindowProxy`](browser-window-proxy.md)).
-
-## Example
-
-To create a sandboxed window, pass `sandbox: true` to `webPreferences`:
-
-```js
-let win
-app.whenReady().then(() => {
-  win = new BrowserWindow({
-    webPreferences: {
-      sandbox: true
-    }
-  })
-  win.loadURL('http://google.com')
-})
-```
-
-In the above code the [`BrowserWindow`](browser-window.md) that was created has Node.js disabled and can communicate
-only via IPC. The use of this option stops Electron from creating a Node.js runtime in the renderer. Also,
-within this new window `window.open` follows the native behavior (by default Electron creates a [`BrowserWindow`](browser-window.md)
-and returns a proxy to this via `window.open`).
-
-[`app.enableSandbox`](app.md#appenablesandbox) can be used to force `sandbox: true` for all `BrowserWindow` instances.
-
-```js
-let win
-app.enableSandbox()
-app.whenReady().then(() => {
-  // no need to pass `sandbox: true` since `app.enableSandbox()` was called.
-  win = new BrowserWindow()
-  win.loadURL('http://google.com')
-})
-```
-
-## Preload
-
-An app can make customizations to sandboxed renderers using a preload script.
-Here's an example:
-
-```js
-let win
-app.whenReady().then(() => {
-  win = new BrowserWindow({
-    webPreferences: {
-      sandbox: true,
-      preload: path.join(app.getAppPath(), 'preload.js')
-    }
-  })
-  win.loadURL('http://google.com')
-})
-```
-
-and preload.js:
-
-```js
-// This file is loaded whenever a javascript context is created. It runs in a
-// private scope that can access a subset of Electron renderer APIs. Without
-// contextIsolation enabled, it's possible to accidentally leak privileged
-// globals like ipcRenderer to web content.
-const { ipcRenderer } = require('electron')
-
-const defaultWindowOpen = window.open
-
-window.open = function customWindowOpen (url, ...args) {
-  ipcRenderer.send('report-window-open', location.origin, url, args)
-  return defaultWindowOpen(url + '?from_electron=1', ...args)
-}
-```
-
-Important things to notice in the preload script:
-
-- Even though the sandboxed renderer doesn't have Node.js running, it still has
-  access to a limited node-like environment: `Buffer`, `process`, `setImmediate`,
-  `clearImmediate` and `require` are available.
-- The preload script must be contained in a single script, but it is possible to have
-  complex preload code composed with multiple modules by using a tool like
-  webpack or browserify. An example of using browserify is below.
-
-To create a browserify bundle and use it as a preload script, something like
-the following should be used:
-
-```sh
-  browserify preload/index.js \
-    -x electron \
-    --insert-global-vars=__filename,__dirname -o preload.js
-```
-
-The `-x` flag should be used with any required module that is already exposed in
-the preload scope, and tells browserify to use the enclosing `require` function
-for it. `--insert-global-vars` will ensure that `process`, `Buffer` and
-`setImmediate` are also taken from the enclosing scope(normally browserify
-injects code for those).
-
-Currently the `require` function provided in the preload scope exposes the
-following modules:
-
-- `electron`
-  - `crashReporter`
-  - `desktopCapturer`
-  - `ipcRenderer`
-  - `nativeImage`
-  - `webFrame`
-- `events`
-- `timers`
-- `url`
-
-More may be added as needed to expose more Electron APIs in the sandbox.
-
-## Rendering untrusted content
-
-Rendering untrusted content in Electron is still somewhat uncharted territory,
-though some apps are finding success (e.g. Beaker Browser). Our goal is to get
-as close to Chrome as we can in terms of the security of sandboxed content, but
-ultimately we will always be behind due to a few fundamental issues:
-
-1. We do not have the dedicated resources or expertise that Chromium has to
-   apply to the security of its product. We do our best to make use of what we
-   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
-   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
-   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
-   to upgrade the version of Electron underlying their app in order for
-   security updates to reach users.
-
-Here are some things to consider before rendering untrusted content:
-
-- A preload script can accidentally leak privileged APIs to untrusted code,
-  unless [`contextIsolation`](../tutorial/security.md#3-enable-context-isolation-for-remote-content)
-  is also enabled.
-- Some bug in the V8 engine may allow malicious code to access the renderer
-  preload APIs, effectively granting full access to the system through the
-  `remote` module. Therefore, it is highly recommended to [disable the `remote`
-  module](../tutorial/security.md#15-disable-the-remote-module).
-  If disabling is not feasible, you should selectively [filter the `remote`
-  module](../tutorial/security.md#16-filter-the-remote-module).
-- While we make our best effort to backport Chromium security fixes to older
-  versions of Electron, we do not make a guarantee that every fix will be
-  backported. Your best chance at staying secure is to be on the latest stable
-  version of Electron.

docs/api/session.md

@@ -492,6 +492,7 @@ win.webContents.session.setCertificateVerifyProc((request, callback) => {
   * `permission` String - The type of requested permission.
     * `clipboard-read` - Request access to read from the clipboard.
     * `media` -  Request access to media devices such as camera, microphone and speakers.
+    * `display-capture` - Request access to capture the screen.
     * `mediaKeySystem` - Request access to DRM protected content.
     * `geolocation` - Request access to user's current location.
     * `notifications` - Request notification creation and the ability to display them in the user's system tray.
@@ -742,9 +743,13 @@ will not work on non-persistent (in-memory) sessions.
 
 **Note:** On macOS and Windows 10 this word will be removed from the OS custom dictionary as well
 
-#### `ses.loadExtension(path)`
+#### `ses.loadExtension(path[, options])`
 
 * `path` String - Path to a directory containing an unpacked Chrome extension
+* `options` Object (optional)
+  * `allowFileAccess` Boolean - Whether to allow the extension to read local files over `file://`
+    protocol and inject content scripts into `file://` pages. This is required e.g. for loading
+    devtools extensions on `file://` URLs. Defaults to false.
 
 Returns `Promise<Extension>` - resolves when the extension is loaded.
 
@@ -767,7 +772,11 @@ const { app, session } = require('electron')
 const path = require('path')
 
 app.on('ready', async () => {
-  await session.defaultSession.loadExtension(path.join(__dirname, 'react-devtools'))
+  await session.defaultSession.loadExtension(
+    path.join(__dirname, 'react-devtools'),
+    // allowFileAccess is required to load the devtools extension on file:// URLs.
+    { allowFileAccess: true }
+  )
   // Note that in order to use the React DevTools extension, you'll need to
   // download and unzip a copy of the extension.
 })

docs/api/share-menu.md

@@ -1,8 +1,4 @@
-## Class: ShareMenu
-
-> Create share menu on macOS.
-
-Process: [Main](../glossary.md#main-process)
+# ShareMenu
 
 The `ShareMenu` class creates [Share Menu][share-menu] on macOS, which can be
 used to share information from the current context to apps, social media
@@ -11,6 +7,12 @@ accounts, and other services.
 For including the share menu as a submenu of other menus, please use the
 `shareMenu` role of [`MenuItem`](menu-item.md).
 
+## Class: ShareMenu
+
+> Create share menu on macOS.
+
+Process: [Main](../glossary.md#main-process)
+
 ### `new ShareMenu(sharingItem)`
 
 * `sharingItem` SharingItem - The item to share.

docs/api/structures/jump-list-category.md

@@ -19,3 +19,7 @@
 property set then its `type` is assumed to be `tasks`. If the `name` property
 is set but the `type` property is omitted then the `type` is assumed to be
 `custom`.
+
+**Note:** The maximum length of a Jump List item's `description` property is
+260 characters. Beyond this limit, the item will not be added to the Jump
+List, nor will it be displayed.

docs/api/structures/jump-list-item.md

@@ -17,7 +17,7 @@
 * `title` String (optional) - The text to be displayed for the item in the Jump List.
   Should only be set if `type` is `task`.
 * `description` String (optional) - Description of the task (displayed in a tooltip).
-  Should only be set if `type` is `task`.
+  Should only be set if `type` is `task`. Maximum length 260 characters.
 * `iconPath` String (optional) - The absolute path to an icon to be displayed in a
   Jump List, which can be an arbitrary resource file that contains an icon
   (e.g. `.ico`, `.exe`, `.dll`). You can usually specify `process.execPath` to

docs/api/structures/upload-file.md

@@ -1,6 +1,6 @@
 # UploadFile Object
 
-* `type` String - `file`.
+* `type` 'file' - `file`.
 * `filePath` String - Path of file to be uploaded.
 * `offset` Integer - Defaults to `0`.
 * `length` Integer - Number of bytes to read from `offset`.

docs/api/structures/upload-raw-data.md

@@ -1,4 +1,4 @@
 # UploadRawData Object
 
-* `type` String - `rawData`.
+* `type` 'rawData' - `rawData`.
 * `bytes` Buffer - Data to be uploaded.

docs/api/system-preferences.md

@@ -130,6 +130,8 @@ This is necessary for events such as `NSUserDefaultsDidChangeNotification`.
   * `userInfo` Record<String, unknown>
   * `object` String
 
+Returns `Number` - The ID of this subscription
+
 Same as `subscribeNotification`, but uses `NSWorkspace.sharedWorkspace.notificationCenter`.
 This is necessary for events such as `NSWorkspaceDidActivateApplicationNotification`.
 

docs/api/touch-bar.md

@@ -1,3 +1,5 @@
+# TouchBar
+
 ## Class: TouchBar
 
 > Create TouchBar layouts for native macOS applications

docs/api/tray.md

@@ -1,3 +1,5 @@
+# Tray
+
 ## Class: Tray
 
 > Add icons and context menus to the system's notification area.

docs/api/web-contents.md

@@ -402,6 +402,9 @@ Returns:
     * `oom` - Process ran out of memory
     * `launch-failed` - Process never successfully launched
     * `integrity-failure` - Windows code integrity checks failed
+  * `exitCode` Integer - The exit code of the process, unless `reason` is
+    `launch-failed`, in which case `exitCode` will be a platform-specific
+    launch failure error code.
 
 Emitted when the renderer process unexpectedly disappears.  This is normally
 because it was crashed or killed.
@@ -1166,6 +1169,7 @@ Ignore application menu shortcuts while this web contents is focused.
     * `url` String - The _resolved_ version of the URL passed to `window.open()`. e.g. opening a window with `window.open('foo')` will yield something like `https://the-origin/the/current/path/foo`.
     * `frameName` String - Name of the window provided in `window.open()`
     * `features` String - Comma separated list of window features provided to `window.open()`.
+
   Returns `{action: 'deny'} | {action: 'allow', overrideBrowserWindowOptions?: BrowserWindowConstructorOptions}` - `deny` cancels the creation of the new
   window. `allow` will allow the new window to be created. Specifying `overrideBrowserWindowOptions` allows customization of the created window.
   Returning an unrecognized value such as a null, undefined, or an object
@@ -1302,8 +1306,7 @@ Inserts `text` to the focused element.
 * `text` String - Content to be searched, must not be empty.
 * `options` Object (optional)
   * `forward` Boolean (optional) - Whether to search forward or backward, defaults to `true`.
-  * `findNext` Boolean (optional) - Whether the operation is first request or a follow up,
-    defaults to `false`.
+  * `findNext` Boolean (optional) - Whether to begin a new text finding session with this request. Should be `true` for initial requests, and `false` for follow-up requests. Defaults to `false`.
   * `matchCase` Boolean (optional) - Whether search should be case-sensitive,
     defaults to `false`.
 
@@ -1658,8 +1661,7 @@ included. Sending Functions, Promises, Symbols, WeakMaps, or WeakSets will
 throw an exception.
 
 > **NOTE**: Sending non-standard JavaScript types such as DOM objects or
-> special Electron objects is deprecated, and will begin throwing an exception
-> starting with Electron 9.
+> special Electron objects will throw an exception.
 
 The renderer process can handle the message by listening to `channel` with the
 [`ipcRenderer`](ipc-renderer.md) module.
@@ -1707,9 +1709,8 @@ Send an asynchronous message to a specific frame in a renderer process via
 chains will not be included. Sending Functions, Promises, Symbols, WeakMaps, or
 WeakSets will throw an exception.
 
-> **NOTE**: Sending non-standard JavaScript types such as DOM objects or
-> special Electron objects is deprecated, and will begin throwing an exception
-> starting with Electron 9.
+> **NOTE:** Sending non-standard JavaScript types such as DOM objects or
+> special Electron objects will throw an exception.
 
 The renderer process can handle the message by listening to `channel` with the
 [`ipcRenderer`](ipc-renderer.md) module.
@@ -1872,7 +1873,7 @@ Returns `Boolean` - If *offscreen rendering* is enabled returns whether it is cu
 * `fps` Integer
 
 If *offscreen rendering* is enabled sets the frame rate to the specified number.
-Only values between 1 and 60 are accepted.
+Only values between 1 and 240 are accepted.
 
 #### `contents.getFrameRate()`
 
@@ -1970,7 +1971,7 @@ The zoom factor is the zoom percent divided by 100, so 300% = 3.0.
 #### `contents.frameRate`
 
 An `Integer` property that sets the frame rate of the web contents to the specified number.
-Only values between 1 and 60 are accepted.
+Only values between 1 and 240 are accepted.
 
 Only applicable if *offscreen rendering* is enabled.
 

docs/api/web-frame-main.md

@@ -86,17 +86,6 @@ In the browser window some HTML APIs like `requestFullScreen` can only be
 invoked by a gesture from the user. Setting `userGesture` to `true` will remove
 this limitation.
 
-#### `frame.executeJavaScriptInIsolatedWorld(worldId, code[, userGesture])`
-
-* `worldId` Integer - The ID of the world to run the javascript in, `0` is the default world, `999` is the world used by Electron's `contextIsolation` feature.  You can provide any integer here.
-* `code` String
-* `userGesture` Boolean (optional) - Default is `false`.
-
-Returns `Promise<unknown>` - A promise that resolves with the result of the executed
-code or is rejected if execution throws or results in a rejected promise.
-
-Works like `executeJavaScript` but evaluates `scripts` in an isolated context.
-
 #### `frame.reload()`
 
 Returns `boolean` - Whether the reload was initiated successfully. Only results in `false` when the frame has no history.

docs/api/webview-tag.md

@@ -5,7 +5,7 @@
 Electron's `webview` tag is based on [Chromium's `webview`][chrome-webview], which
 is undergoing dramatic architectural changes. This impacts the stability of `webviews`,
 including rendering, navigation, and event routing. We currently recommend to not
-use the `webview` tag and to consider alternatives, like `iframe`, Electron's `BrowserView`,
+use the `webview` tag and to consider alternatives, like `iframe`, [Electron's `BrowserView`](browser-view.md),
 or an architecture that avoids embedded content altogether.
 
 ## Enabling
@@ -515,8 +515,7 @@ Inserts `text` to the focused element.
 * `text` String - Content to be searched, must not be empty.
 * `options` Object (optional)
   * `forward` Boolean (optional) - Whether to search forward or backward, defaults to `true`.
-  * `findNext` Boolean (optional) - Whether the operation is first request or a follow up,
-    defaults to `false`.
+  * `findNext` Boolean (optional) - Whether to begin a new text finding session with this request. Should be `true` for initial requests, and `false` for follow-up requests. Defaults to `false`.
   * `matchCase` Boolean (optional) - Whether search should be case-sensitive,
     defaults to `false`.
 

docs/api/window-open.md

@@ -83,9 +83,9 @@ const mainWindow = new BrowserWindow()
 
 mainWindow.webContents.setWindowOpenHandler(({ url }) => {
   if (url.startsWith('https://github.com/')) {
-    return true
+    return { action: 'allow' }
   }
-  return false
+  return { action: 'deny' }
 })
 
 mainWindow.webContents.on('did-create-window', (childWindow) => {

docs/breaking-changes.md

@@ -6,14 +6,52 @@ Breaking changes will be documented here, and deprecation warnings added to JS c
 
 This document uses the following convention to categorize breaking changes:
 
-- **API Changed:** An API was changed in such a way that code that has not been updated is guaranteed to throw an exception.
-- **Behavior Changed:** The behavior of Electron has changed, but not in such a way that an exception will necessarily be thrown.
-- **Default Changed:** Code depending on the old default may break, not necessarily throwing an exception. The old behavior can be restored by explicitly specifying the value.
-- **Deprecated:** An API was marked as deprecated. The API will continue to function, but will emit a deprecation warning, and will be removed in a future release.
-- **Removed:** An API or feature was removed, and is no longer supported by Electron.
+* **API Changed:** An API was changed in such a way that code that has not been updated is guaranteed to throw an exception.
+* **Behavior Changed:** The behavior of Electron has changed, but not in such a way that an exception will necessarily be thrown.
+* **Default Changed:** Code depending on the old default may break, not necessarily throwing an exception. The old behavior can be restored by explicitly specifying the value.
+* **Deprecated:** An API was marked as deprecated. The API will continue to function, but will emit a deprecation warning, and will be removed in a future release.
+* **Removed:** An API or feature was removed, and is no longer supported by Electron.
+
+## Planned Breaking API Changes (14.0)
+
+### API Changed: `window.(open)`
+
+The optional parameter `frameName` will no longer set the title of the window. This now follows the specification described by the [native documentation](https://developer.mozilla.org/en-US/docs/Web/API/Window/open#parameters) under the corresponding parameter `windowName`.
+
+If you were using this parameter to set the title of a window, you can instead use [win.setTitle(title)](https://www.electronjs.org/docs/api/browser-window#winsettitletitle).
+
+### Removed: `worldSafeExecuteJavaScript`
+
+In Electron 14, `worldSafeExecuteJavaScript` will be removed.  There is no alternative, please
+ensure your code works with this property enabled.  It has been enabled by default since Electron
+12.
+
+You will be affected by this change if you use either `webFrame.executeJavaScript` or `webFrame.executeJavaScriptInIsolatedWorld`. You will need to ensure that values returned by either of those methods are supported by the [Context Bridge API](api/context-bridge.md#parameter--error--return-type-support) as these methods use the same value passing semantics.
 
 ## Planned Breaking API Changes (13.0)
 
+### API Changed: `session.setPermissionCheckHandler(handler)`
+
+The `handler` methods first parameter was previously always a `webContents`, it can now sometimes be `null`.  You should use the `requestingOrigin`, `embeddingOrigin` and `securityOrigin` properties to respond to the permission check correctly.  As the `webContents` can be `null` it can no longer be relied on.
+
+```js
+// Old code
+session.setPermissionCheckHandler((webContents, permission) => {
+  if (webContents.getURL().startsWith('https://google.com/') && permission === 'notification') {
+    return true
+  }
+  return false
+})
+
+// Replace with
+session.setPermissionCheckHandler((webContents, permission, requestingOrigin) => {
+  if (new URL(requestingOrigin).hostname === 'google.com' && permission === 'notification') {
+    return true
+  }
+  return false
+})
+```
+
 ### Removed: `shell.moveItemToTrash()`
 
 The deprecated synchronous `shell.moveItemToTrash()` API has been removed. Use
@@ -26,6 +64,78 @@ shell.moveItemToTrash(path)
 shell.trashItem(path).then(/* ... */)
 ```
 
+### Removed: `BrowserWindow` extension APIs
+
+The deprecated extension APIs have been removed:
+
+* `BrowserWindow.addExtension(path)`
+* `BrowserWindow.addDevToolsExtension(path)`
+* `BrowserWindow.removeExtension(name)`
+* `BrowserWindow.removeDevToolsExtension(name)`
+* `BrowserWindow.getExtensions()`
+* `BrowserWindow.getDevToolsExtensions()`
+
+Use the session APIs instead:
+
+* `ses.loadExtension(path)`
+* `ses.removeExtension(extension_id)`
+* `ses.getAllExtensions()`
+
+```js
+// Removed in Electron 13
+BrowserWindow.addExtension(path)
+BrowserWindow.addDevToolsExtension(path)
+// Replace with
+session.defaultSession.loadExtension(path)
+```
+
+```js
+// Removed in Electron 13
+BrowserWindow.removeExtension(name)
+BrowserWindow.removeDevToolsExtension(name)
+// Replace with
+session.defaultSession.removeExtension(extension_id)
+```
+
+```js
+// Removed in Electron 13
+BrowserWindow.getExtensions()
+BrowserWindow.getDevToolsExtensions()
+// Replace with
+session.defaultSession.getAllExtensions()
+```
+
+### Removed: methods in `systemPreferences`
+
+The following `systemPreferences` methods have been deprecated:
+
+* `systemPreferences.isDarkMode()`
+* `systemPreferences.isInvertedColorScheme()`
+* `systemPreferences.isHighContrastColorScheme()`
+
+Use the following `nativeTheme` properties instead:
+
+* `nativeTheme.shouldUseDarkColors`
+* `nativeTheme.shouldUseInvertedColorScheme`
+* `nativeTheme.shouldUseHighContrastColors`
+
+```js
+// Removed in Electron 13
+systemPreferences.isDarkMode()
+// Replace with
+nativeTheme.shouldUseDarkColors
+
+// Removed in Electron 13
+systemPreferences.isInvertedColorScheme()
+// Replace with
+nativeTheme.shouldUseInvertedColorScheme
+
+// Removed in Electron 13
+systemPreferences.isHighContrastColorScheme()
+// Replace with
+nativeTheme.shouldUseHighContrastColors
+```
+
 ## Planned Breaking API Changes (12.0)
 
 ### Removed: Pepper Flash support
@@ -34,6 +144,15 @@ Chromium has removed support for Flash, and so we must follow suit. See
 Chromium's [Flash Roadmap](https://www.chromium.org/flash-roadmap) for more
 details.
 
+### Default Changed: `worldSafeExecuteJavaScript` defaults to `true`
+
+In Electron 12, `worldSafeExecuteJavaScript` will be enabled by default.  To restore
+the previous behavior, `worldSafeExecuteJavaScript: false` must be specified in WebPreferences.
+Please note that setting this option to `false` is **insecure**.
+
+This option will be removed in Electron 14 so please migrate your code to support the default
+value.
+
 ### Default Changed: `contextIsolation` defaults to `true`
 
 In Electron 12, `contextIsolation` will be enabled by default.  To restore
@@ -41,6 +160,9 @@ the previous behavior, `contextIsolation: false` must be specified in WebPrefere
 
 We [recommend having contextIsolation enabled](https://github.com/electron/electron/blob/master/docs/tutorial/security.md#3-enable-context-isolation-for-remote-content) for the security of your application.
 
+Another implication is that `require()` cannot be used in the renderer process unless
+`nodeIntegration` is `true` and `contextIsolation` is `false`.
+
 For more details see: https://github.com/electron/electron/issues/23506
 
 ### Removed: `crashReporter.getCrashesDirectory()`
@@ -60,12 +182,12 @@ app.getPath('crashDumps')
 The following `crashReporter` methods are no longer available in the renderer
 process:
 
-- `crashReporter.start`
-- `crashReporter.getLastCrashReport`
-- `crashReporter.getUploadedReports`
-- `crashReporter.getUploadToServer`
-- `crashReporter.setUploadToServer`
-- `crashReporter.getCrashesDirectory`
+* `crashReporter.start`
+* `crashReporter.getLastCrashReport`
+* `crashReporter.getUploadedReports`
+* `crashReporter.getUploadToServer`
+* `crashReporter.setUploadToServer`
+* `crashReporter.getCrashesDirectory`
 
 They should be called only from the main process.
 
@@ -116,6 +238,7 @@ shell.trashItem(path).then(/* ... */)
 ## Planned Breaking API Changes (11.0)
 
 ### Removed: `BrowserView.{destroy, fromId, fromWebContents, getAllViews}` and `id` property of `BrowserView`
+
 The experimental APIs `BrowserView.{destroy, fromId, fromWebContents, getAllViews}`
 have now been removed. Additionally, the `id` property of `BrowserView`
 has also been removed.
@@ -155,12 +278,12 @@ app.getPath('crashDumps')
 Calling the following `crashReporter` methods from the renderer process is
 deprecated:
 
-- `crashReporter.start`
-- `crashReporter.getLastCrashReport`
-- `crashReporter.getUploadedReports`
-- `crashReporter.getUploadToServer`
-- `crashReporter.setUploadToServer`
-- `crashReporter.getCrashesDirectory`
+* `crashReporter.start`
+* `crashReporter.getLastCrashReport`
+* `crashReporter.getUploadedReports`
+* `crashReporter.getUploadToServer`
+* `crashReporter.setUploadToServer`
+* `crashReporter.getCrashesDirectory`
 
 The only non-deprecated methods remaining in the `crashReporter` module in the
 renderer are `addExtraParameter`, `removeExtraParameter` and `getParameters`.
@@ -202,6 +325,7 @@ We [recommend moving away from the remote
 module](https://medium.com/@nornagon/electrons-remote-module-considered-harmful-70d69500f31).
 
 ### `protocol.unregisterProtocol`
+
 ### `protocol.uninterceptProtocol`
 
 The APIs are now synchronous and the optional callback is no longer needed.
@@ -214,14 +338,23 @@ protocol.unregisterProtocol(scheme)
 ```
 
 ### `protocol.registerFileProtocol`
+
 ### `protocol.registerBufferProtocol`
+
 ### `protocol.registerStringProtocol`
+
 ### `protocol.registerHttpProtocol`
+
 ### `protocol.registerStreamProtocol`
+
 ### `protocol.interceptFileProtocol`
+
 ### `protocol.interceptStringProtocol`
+
 ### `protocol.interceptBufferProtocol`
+
 ### `protocol.interceptHttpProtocol`
+
 ### `protocol.interceptStreamProtocol`
 
 The APIs are now synchronous and the optional callback is no longer needed.
@@ -266,6 +399,7 @@ For more detailed information see [#18397](https://github.com/electron/electron/
 ### Deprecated: `BrowserWindow` extension APIs
 
 The following extension APIs have been deprecated:
+
 * `BrowserWindow.addExtension(path)`
 * `BrowserWindow.addDevToolsExtension(path)`
 * `BrowserWindow.removeExtension(name)`
@@ -274,6 +408,7 @@ The following extension APIs have been deprecated:
 * `BrowserWindow.getDevToolsExtensions()`
 
 Use the session APIs instead:
+
 * `ses.loadExtension(path)`
 * `ses.removeExtension(extension_id)`
 * `ses.getAllExtensions()`
@@ -354,7 +489,7 @@ Clone Algorithm][SCA], the same algorithm used to serialize messages for
 `postMessage`. This brings about a 2x performance improvement for large
 messages, but also brings some breaking changes in behavior.
 
-- Sending Functions, Promises, WeakMaps, WeakSets, or objects containing any
+* Sending Functions, Promises, WeakMaps, WeakSets, or objects containing any
   such values, over IPC will now throw an exception, instead of silently
   converting the functions to `undefined`.
 
@@ -368,21 +503,21 @@ ipcRenderer.send('channel', { value: 3, someFunction: () => {} })
 // => throws Error("() => {} could not be cloned.")
 ```
 
-- `NaN`, `Infinity` and `-Infinity` will now be correctly serialized, instead
+* `NaN`, `Infinity` and `-Infinity` will now be correctly serialized, instead
   of being converted to `null`.
-- Objects containing cyclic references will now be correctly serialized,
+* Objects containing cyclic references will now be correctly serialized,
   instead of being converted to `null`.
-- `Set`, `Map`, `Error` and `RegExp` values will be correctly serialized,
+* `Set`, `Map`, `Error` and `RegExp` values will be correctly serialized,
   instead of being converted to `{}`.
-- `BigInt` values will be correctly serialized, instead of being converted to
+* `BigInt` values will be correctly serialized, instead of being converted to
   `null`.
-- Sparse arrays will be serialized as such, instead of being converted to dense
+* Sparse arrays will be serialized as such, instead of being converted to dense
   arrays with `null`s.
-- `Date` objects will be transferred as `Date` objects, instead of being
+* `Date` objects will be transferred as `Date` objects, instead of being
   converted to their ISO string representation.
-- Typed Arrays (such as `Uint8Array`, `Uint16Array`, `Uint32Array` and so on)
+* Typed Arrays (such as `Uint8Array`, `Uint16Array`, `Uint32Array` and so on)
   will be transferred as such, instead of being converted to Node.js `Buffer`.
-- Node.js `Buffer` objects will be transferred as `Uint8Array`s. You can
+* Node.js `Buffer` objects will be transferred as `Uint8Array`s. You can
   convert a `Uint8Array` back to a Node.js `Buffer` by wrapping the underlying
   `ArrayBuffer`:
 
@@ -451,6 +586,7 @@ limits are now fixed at a minimum of 0.25 and a maximum of 5.0, as defined
 ### Deprecated events in `systemPreferences`
 
 The following `systemPreferences` events have been deprecated:
+
 * `inverted-color-scheme-changed`
 * `high-contrast-color-scheme-changed`
 
@@ -468,11 +604,13 @@ nativeTheme.on('updated', () => { /* ... */ })
 ### Deprecated: methods in `systemPreferences`
 
 The following `systemPreferences` methods have been deprecated:
+
 * `systemPreferences.isDarkMode()`
 * `systemPreferences.isInvertedColorScheme()`
 * `systemPreferences.isHighContrastColorScheme()`
 
 Use the following `nativeTheme` properties instead:
+
 * `nativeTheme.shouldUseDarkColors`
 * `nativeTheme.shouldUseInvertedColorScheme`
 * `nativeTheme.shouldUseHighContrastColors`
@@ -593,6 +731,55 @@ Note that `webkitdirectory` no longer exposes the path to the selected folder.
 If you require the path to the selected folder rather than the folder contents,
 see the `dialog.showOpenDialog` API ([link](https://github.com/electron/electron/blob/master/docs/api/dialog.md#dialogshowopendialogbrowserwindow-options)).
 
+### API Changed: Callback-based versions of promisified APIs
+
+Electron 5 and Electron 6 introduced Promise-based versions of existing
+asynchronous APIs and deprecated their older, callback-based counterparts.
+In Electron 7, all deprecated callback-based APIs are now removed.
+
+These functions now only return Promises:
+
+* `app.getFileIcon()` [#15742](https://github.com/electron/electron/pull/15742)
+* `app.dock.show()` [#16904](https://github.com/electron/electron/pull/16904)
+* `contentTracing.getCategories()` [#16583](https://github.com/electron/electron/pull/16583)
+* `contentTracing.getTraceBufferUsage()` [#16600](https://github.com/electron/electron/pull/16600)
+* `contentTracing.startRecording()` [#16584](https://github.com/electron/electron/pull/16584)
+* `contentTracing.stopRecording()` [#16584](https://github.com/electron/electron/pull/16584)
+* `contents.executeJavaScript()` [#17312](https://github.com/electron/electron/pull/17312)
+* `cookies.flushStore()` [#16464](https://github.com/electron/electron/pull/16464)
+* `cookies.get()` [#16464](https://github.com/electron/electron/pull/16464)
+* `cookies.remove()` [#16464](https://github.com/electron/electron/pull/16464)
+* `cookies.set()` [#16464](https://github.com/electron/electron/pull/16464)
+* `debugger.sendCommand()` [#16861](https://github.com/electron/electron/pull/16861)
+* `dialog.showCertificateTrustDialog()` [#17181](https://github.com/electron/electron/pull/17181)
+* `inAppPurchase.getProducts()` [#17355](https://github.com/electron/electron/pull/17355)
+* `inAppPurchase.purchaseProduct()`[#17355](https://github.com/electron/electron/pull/17355)
+* `netLog.stopLogging()` [#16862](https://github.com/electron/electron/pull/16862)
+* `session.clearAuthCache()` [#17259](https://github.com/electron/electron/pull/17259)
+* `session.clearCache()`  [#17185](https://github.com/electron/electron/pull/17185)
+* `session.clearHostResolverCache()` [#17229](https://github.com/electron/electron/pull/17229)
+* `session.clearStorageData()` [#17249](https://github.com/electron/electron/pull/17249)
+* `session.getBlobData()` [#17303](https://github.com/electron/electron/pull/17303)
+* `session.getCacheSize()`  [#17185](https://github.com/electron/electron/pull/17185)
+* `session.resolveProxy()` [#17222](https://github.com/electron/electron/pull/17222)
+* `session.setProxy()`  [#17222](https://github.com/electron/electron/pull/17222)
+* `shell.openExternal()` [#16176](https://github.com/electron/electron/pull/16176)
+* `webContents.loadFile()` [#15855](https://github.com/electron/electron/pull/15855)
+* `webContents.loadURL()` [#15855](https://github.com/electron/electron/pull/15855)
+* `webContents.hasServiceWorker()` [#16535](https://github.com/electron/electron/pull/16535)
+* `webContents.printToPDF()` [#16795](https://github.com/electron/electron/pull/16795)
+* `webContents.savePage()` [#16742](https://github.com/electron/electron/pull/16742)
+* `webFrame.executeJavaScript()` [#17312](https://github.com/electron/electron/pull/17312)
+* `webFrame.executeJavaScriptInIsolatedWorld()` [#17312](https://github.com/electron/electron/pull/17312)
+* `webviewTag.executeJavaScript()` [#17312](https://github.com/electron/electron/pull/17312)
+* `win.capturePage()` [#15743](https://github.com/electron/electron/pull/15743)
+
+These functions now have two forms, synchronous and Promise-based asynchronous:
+
+* `dialog.showMessageBox()`/`dialog.showMessageBoxSync()` [#17298](https://github.com/electron/electron/pull/17298)
+* `dialog.showOpenDialog()`/`dialog.showOpenDialogSync()` [#16973](https://github.com/electron/electron/pull/16973)
+* `dialog.showSaveDialog()`/`dialog.showSaveDialogSync()` [#17054](https://github.com/electron/electron/pull/17054)
+
 ## Planned Breaking API Changes (6.0)
 
 ### API Changed: `win.setMenu(null)` is now `win.removeMenu()`
@@ -604,19 +791,6 @@ win.setMenu(null)
 win.removeMenu()
 ```
 
-### API Changed: `contentTracing.getTraceBufferUsage()` is now a promise
-
-```js
-// Deprecated
-contentTracing.getTraceBufferUsage((percentage, value) => {
-  // do something
-})
-// Replace with
-contentTracing.getTraceBufferUsage().then(infoObject => {
-  // infoObject has percentage and value fields
-})
-```
-
 ### API Changed: `electron.screen` in the renderer process should be accessed via `remote`
 
 ```js
@@ -755,6 +929,31 @@ webFrame.setSpellCheckProvider('en-US', {
 })
 ```
 
+### API Changed: `webContents.getZoomLevel` and `webContents.getZoomFactor` are now synchronous
+
+`webContents.getZoomLevel` and `webContents.getZoomFactor` no longer take callback parameters,
+instead directly returning their number values.
+
+```js
+// Deprecated
+webContents.getZoomLevel((level) => {
+  console.log(level)
+})
+// Replace with
+const level = webContents.getZoomLevel()
+console.log(level)
+```
+
+```js
+// Deprecated
+webContents.getZoomFactor((factor) => {
+  console.log(factor)
+})
+// Replace with
+const factor = webContents.getZoomFactor()
+console.log(factor)
+```
+
 ## Planned Breaking API Changes (4.0)
 
 The following list includes the breaking API changes made in Electron 4.0.

docs/development/build-instructions-gn.md

@@ -1,6 +1,8 @@
 # Build Instructions
 
-Follow the guidelines below for building Electron.
+Follow the guidelines below for building **Electron itself**, for the purposes of creating custom Electron binaries. For bundling and distributing your app code with the prebuilt Electron binaries, see the [application distribution][application-distribution] guide.
+
+[application-distribution]: ../tutorial/application-distribution.md
 
 ## Platform prerequisites
 
@@ -86,8 +88,6 @@ $ gclient sync -f
 ```sh
 $ cd src
 $ export CHROMIUM_BUILDTOOLS_PATH=`pwd`/buildtools
-# this next line is needed only if building with sccache
-$ export GN_EXTRA_ARGS="${GN_EXTRA_ARGS} cc_wrapper=\"${PWD}/electron/external_binaries/sccache\""
 $ gn gen out/Testing --args="import(\"//electron/build/args/testing.gn\") $GN_EXTRA_ARGS"
 ```
 
@@ -141,12 +141,6 @@ This will build all of what was previously 'libchromiumcontent' (i.e. the
 `content/` directory of `chromium` and its dependencies, incl. WebKit and V8),
 so it will take a while.
 
-To speed up subsequent builds, you can use [sccache][sccache]. Add the GN arg
-`cc_wrapper = "sccache"` by running `gn args out/Testing` to bring up an
-editor and adding a line to the end of the file.
-
-[sccache]: https://github.com/mozilla/sccache
-
 The built executable will be under `./out/Testing`:
 
 ```sh
@@ -189,7 +183,6 @@ Not all combinations of source and target CPU/OS are supported by Chromium.
 | Windows x64 | Windows x86   | Automatically tested |
 | Linux x64   | Linux x86     | Automatically tested |
 
-
 If you test other combinations and find them to work, please update this document :)
 
 See the GN reference for allowable values of [`target_os`][target_os values]

docs/development/build-instructions-linux.md

@@ -1,6 +1,8 @@
 # Build Instructions (Linux)
 
-Follow the guidelines below for building Electron on Linux.
+Follow the guidelines below for building **Electron itself** on Linux, for the purposes of creating custom Electron binaries. For bundling and distributing your app code with the prebuilt Electron binaries, see the [application distribution][application-distribution] guide.
+
+[application-distribution]: ../tutorial/application-distribution.md
 
 ## Prerequisites
 
@@ -55,6 +57,15 @@ $ sudo dnf install clang dbus-devel gtk3-devel libnotify-devel \
                    nss-devel python-dbusmock openjdk-8-jre
 ```
 
+On Arch Linux / Manjaro, install the following libraries:
+
+```sh
+$ sudo pacman -Syu base-devel clang libdbus gtk2 libnotify \
+                   libgnome-keyring alsa-lib libcap libcups libxtst \
+                   libxss nss gcc-multilib curl gperf bison \
+                   python2 python-dbusmock jdk8-openjdk
+```
+
 Other distributions may offer similar packages for installation via package
 managers such as pacman. Or one can compile from source code.
 

docs/development/build-instructions-macos.md

@@ -1,6 +1,8 @@
 # Build Instructions (macOS)
 
-Follow the guidelines below for building Electron on macOS.
+Follow the guidelines below for building **Electron itself** on macOS, for the purposes of creating custom Electron binaries. For bundling and distributing your app code with the prebuilt Electron binaries, see the [application distribution][application-distribution] guide.
+
+[application-distribution]: ../tutorial/application-distribution.md
 
 ## Prerequisites
 
@@ -42,7 +44,7 @@ $ pip install pyobjc
 If you're developing Electron and don't plan to redistribute your
 custom Electron build, you may skip this section.
 
-Official Electron builds are built with [Xcode 9.4.1](http://adcdownload.apple.com/Developer_Tools/Xcode_9.4.1/Xcode_9.4.1.xip), and the macOS 10.13 SDK.  Building with a newer SDK works too, but the releases currently use the 10.13 SDK.
+Official Electron builds are built with [Xcode 12.2](https://download.developer.apple.com/Developer_Tools/Xcode_12.2/Xcode_12.2.xip), and the macOS 11.0 SDK. Building with a newer SDK works too, but the releases currently use the 11.0 SDK.
 
 ## Building Electron
 

docs/development/build-instructions-windows.md

@@ -1,6 +1,8 @@
 # Build Instructions (Windows)
 
-Follow the guidelines below for building Electron on Windows.
+Follow the guidelines below for building **Electron itself** on Windows, for the purposes of creating custom Electron binaries. For bundling and distributing your app code with the prebuilt Electron binaries, see the [application distribution][application-distribution] guide.
+
+[application-distribution]: ../tutorial/application-distribution.md
 
 ## Prerequisites
 

docs/development/coding-style.md

@@ -66,11 +66,11 @@ formatted correctly.
 
 Electron APIs uses the same capitalization scheme as Node.js:
 
-- When the module itself is a class like `BrowserWindow`, use `PascalCase`.
-- When the module is a set of APIs, like `globalShortcut`, use `camelCase`.
-- When the API is a property of object, and it is complex enough to be in a
+* When the module itself is a class like `BrowserWindow`, use `PascalCase`.
+* When the module is a set of APIs, like `globalShortcut`, use `camelCase`.
+* When the API is a property of object, and it is complex enough to be in a
   separate chapter like `win.webContents`, use `mixedCase`.
-- For other non-module APIs, use natural titles, like `<webview> Tag` or
+* For other non-module APIs, use natural titles, like `<webview> Tag` or
   `Process Object`.
 
 When creating a new API, it is preferred to use getters and setters instead of

docs/development/issues.md

@@ -33,8 +33,7 @@ contributing, and more. Please use the issue tracker for bugs only!
 To submit a bug report:
 
 When opening a new issue in the [`electron/electron` issue tracker](https://github.com/electron/electron/issues/new/choose), users
-will be presented with [a template](https://github.com/electron/electron/blob/master/.github/ISSUE_TEMPLATE/Bug_report.md)
-that should be filled in.
+will be presented with a template that should be filled in.
 
 If you believe that you have found a bug in Electron, please fill out the template
 to the best of your ability.

docs/development/pull-requests.md

@@ -36,9 +36,9 @@ $ git fetch upstream
 Build steps and dependencies differ slightly depending on your operating system.
 See these detailed guides on building Electron locally:
 
-* [Building on macOS](https://electronjs.org/docs/development/build-instructions-macos)
-* [Building on Linux](https://electronjs.org/docs/development/build-instructions-linux)
-* [Building on Windows](https://electronjs.org/docs/development/build-instructions-windows)
+* [Building on macOS](build-instructions-macos.md)
+* [Building on Linux](build-instructions-linux.md)
+* [Building on Windows](build-instructions-windows.md)
 
 Once you've built the project locally, you're ready to start making changes!
 
@@ -63,7 +63,7 @@ or tests in the `spec/` folder.
 Please be sure to run `npm run lint` from time to time on any code changes
 to ensure that they follow the project's code style.
 
-See [coding style](https://electronjs.org/docs/development/coding-style) for
+See [coding style](coding-style.md) for
 more information about best practice when modifying code in different parts of
 the project.
 
@@ -91,29 +91,29 @@ Before a pull request can be merged, it **must** have a pull request title with
 
 Examples of commit messages with semantic prefixes:
 
-- `fix: don't overwrite prevent_default if default wasn't prevented`
-- `feat: add app.isPackaged() method`
-- `docs: app.isDefaultProtocolClient is now available on Linux`
+* `fix: don't overwrite prevent_default if default wasn't prevented`
+* `feat: add app.isPackaged() method`
+* `docs: app.isDefaultProtocolClient is now available on Linux`
 
 Common prefixes:
 
-- fix: A bug fix
-- feat: A new feature
-- docs: Documentation changes
-- test: Adding missing tests or correcting existing tests
-- build: Changes that affect the build system
-- ci: Changes to our CI configuration files and scripts
-- perf: A code change that improves performance
-- refactor: A code change that neither fixes a bug nor adds a feature
-- style: Changes that do not affect the meaning of the code (linting)
-- vendor: Bumping a dependency like libchromiumcontent or node
+* fix: A bug fix
+* feat: A new feature
+* docs: Documentation changes
+* test: Adding missing tests or correcting existing tests
+* build: Changes that affect the build system
+* ci: Changes to our CI configuration files and scripts
+* perf: A code change that improves performance
+* refactor: A code change that neither fixes a bug nor adds a feature
+* style: Changes that do not affect the meaning of the code (linting)
+* vendor: Bumping a dependency like libchromiumcontent or node
 
 Other things to keep in mind when writing a commit message:
 
 1. The first line should:
-   - contain a short description of the change (preferably 50 characters or less,
+   * contain a short description of the change (preferably 50 characters or less,
      and no more than 72 characters)
-   - be entirely in lowercase with the exception of proper nouns, acronyms, and
+   * be entirely in lowercase with the exception of proper nouns, acronyms, and
    the words that refer to code, like function/variable names
 2. Keep the second line blank.
 3. Wrap all other lines at 72 columns.
@@ -144,7 +144,7 @@ master.
 ### Step 7: Test
 
 Bug fixes and features should always come with tests. A
-[testing guide](https://electronjs.org/docs/development/testing) has been
+[testing guide](testing.md) has been
 provided to make the process easier. Looking at other tests to see how they
 should be structured can also help.
 

docs/development/source-code-directory-structure.md

@@ -100,7 +100,5 @@ script/ - The set of all scripts Electron runs for a variety of purposes.
     └── uploaders/ - Uploads various release-related files during release.
 ```
 
-* **tools** - Helper scripts used by GN files.
-  * Scripts put here should never be invoked by users directly, unlike those in `script`.
 * **typings** - TypeScript typings for Electron's internal code.
 * **vendor** - Source code for some third party dependencies.

docs/fiddles/features/drag-and-drop/index.html

@@ -7,12 +7,9 @@
 </head>
 <body>
     <h1>Hello World!</h1>
-    <p>
-        We are using node <script>document.write(process.versions.node)</script>,
-        Chrome <script>document.write(process.versions.chrome)</script>,
-        and Electron <script>document.write(process.versions.electron)</script>.
-    </p>
-    <a href="#" id="drag">Drag me</a>
+    <p>Drag the boxes below to somewhere in your OS (Finder/Explorer, Desktop, etc.) to copy an example markdown file.</p>
+    <div style="border:2px solid black;border-radius:3px;padding:5px;display:inline-block" draggable="true" id="drag1">Drag me - File 1</div>
+    <div style="border:2px solid black;border-radius:3px;padding:5px;display:inline-block" draggable="true" id="drag2">Drag me - File 2</div>
     <script src="renderer.js"></script>
 </body>
 </html>

docs/fiddles/features/drag-and-drop/main.js

@@ -1,21 +1,28 @@
 const { app, BrowserWindow, ipcMain, nativeImage, NativeImage } = require('electron')
-const fs = require('fs');
-const http = require('http');
+const path = require('path')
+const fs = require('fs')
+const https = require('https')
 
-function createWindow () {
+function createWindow() {
   const win = new BrowserWindow({
     width: 800,
     height: 600,
     webPreferences: {
-      nodeIntegration: true
+      preload: path.join(__dirname, 'preload.js')
     }
   })
 
   win.loadFile('index.html')
 }
-const iconName = 'iconForDragAndDrop.png';
-const icon = fs.createWriteStream(`${process.cwd()}/${iconName}`);
-http.get('http://img.icons8.com/ios/452/drag-and-drop.png', (response) => {
+
+const iconName = path.join(__dirname, 'iconForDragAndDrop.png');
+const icon = fs.createWriteStream(iconName);
+
+// Create a new file to copy - you can also copy existing files.
+fs.writeFileSync(path.join(__dirname, 'drag-and-drop-1.md'), '# First file to test drag and drop')
+fs.writeFileSync(path.join(__dirname, 'drag-and-drop-2.md'), '# Second file to test drag and drop')
+
+https.get('https://img.icons8.com/ios/452/drag-and-drop.png', (response) => {
   response.pipe(icon);
 });
 
@@ -23,8 +30,8 @@ app.whenReady().then(createWindow)
 
 ipcMain.on('ondragstart', (event, filePath) => {
   event.sender.startDrag({
-    file: filePath,
-    icon: `${process.cwd()}/${iconName}`
+    file: path.join(__dirname, filePath),
+    icon: iconName,
   })
 })
 

docs/fiddles/features/drag-and-drop/preload.js

@@ -0,0 +1,8 @@
+const { contextBridge, ipcRenderer } = require('electron')
+const path = require('path')
+
+contextBridge.exposeInMainWorld('electron', {
+  startDrag: (fileName) => {
+    ipcRenderer.send('ondragstart', fileName)
+  }
+})

docs/fiddles/features/drag-and-drop/renderer.js

@@ -1,9 +1,9 @@
-const { ipcRenderer } = require('electron')
-const fs = require('fs')
-
-document.getElementById('drag').ondragstart = (event) => {
-  const fileName = 'drag-and-drop.md'
-  fs.writeFileSync(fileName, '# Test drag and drop');
+document.getElementById('drag1').ondragstart = (event) => {
   event.preventDefault()
-  ipcRenderer.send('ondragstart', process.cwd() + `/${fileName}`)
+  window.electron.startDrag('drag-and-drop-1.md')
+}
+
+document.getElementById('drag2').ondragstart = (event) => {
+  event.preventDefault()
+  window.electron.startDrag('drag-and-drop-2.md')
 }

docs/fiddles/features/macos-dark-mode/main.js

@@ -1,11 +1,12 @@
 const { app, BrowserWindow, ipcMain, nativeTheme } = require('electron')
+const path = require('path')
 
 function createWindow () {
   const win = new BrowserWindow({
     width: 800,
     height: 600,
     webPreferences: {
-      nodeIntegration: true
+      preload: path.join(__dirname, 'preload.js')
     }
   })
 
@@ -25,16 +26,18 @@ function createWindow () {
   })
 }
 
-app.whenReady().then(createWindow)
+app.whenReady().then(() => {
+  createWindow()
+
+  app.on('activate', () => {
+    if (BrowserWindow.getAllWindows().length === 0) {
+      createWindow()
+    }
+  })
+})
 
 app.on('window-all-closed', () => {
   if (process.platform !== 'darwin') {
     app.quit()
   }
 })
-
-app.on('activate', () => {
-  if (BrowserWindow.getAllWindows().length === 0) {
-    createWindow()
-  }
-})

docs/fiddles/features/macos-dark-mode/preload.js

@@ -0,0 +1,6 @@
+const { contextBridge, ipcRenderer } = require('electron')
+
+contextBridge.exposeInMainWorld('darkMode', {
+  toggle: () => ipcRenderer.invoke('dark-mode:toggle'),
+  system: () => ipcRenderer.invoke('dark-mode:system')
+})

docs/fiddles/features/macos-dark-mode/renderer.js

@@ -1,11 +1,9 @@
-const { ipcRenderer } = require('electron')
-
 document.getElementById('toggle-dark-mode').addEventListener('click', async () => {
-  const isDarkMode = await ipcRenderer.invoke('dark-mode:toggle')
+  const isDarkMode = await window.darkMode.toggle()
   document.getElementById('theme-source').innerHTML = isDarkMode ? 'Dark' : 'Light'
 })
 
 document.getElementById('reset-to-system').addEventListener('click', async () => {
-  await ipcRenderer.invoke('dark-mode:system')
+  await window.darkMode.system()
   document.getElementById('theme-source').innerHTML = 'System'
 })

docs/fiddles/features/macos-dock-menu/index.html

@@ -7,10 +7,6 @@
 </head>
 <body>
     <h1>Hello World!</h1>
-    <p>
-        We are using node <script>document.write(process.versions.node)</script>,
-        Chrome <script>document.write(process.versions.chrome)</script>,
-        and Electron <script>document.write(process.versions.electron)</script>.
-    </p>
+    <p>Right click the dock icon to see the custom menu options.</p>
 </body>
 </html>

docs/fiddles/features/macos-dock-menu/main.js

@@ -4,9 +4,6 @@ function createWindow () {
   const win = new BrowserWindow({
     width: 800,
     height: 600,
-    webPreferences: {
-      nodeIntegration: true
-    }
   })
 
   win.loadFile('index.html')
@@ -27,7 +24,9 @@ const dockMenu = Menu.buildFromTemplate([
 ])
 
 app.whenReady().then(() => {
-  app.dock.setMenu(dockMenu)
+  if (process.platform === 'darwin') {
+    app.dock.setMenu(dockMenu)
+  }
 }).then(createWindow)
 
 app.on('window-all-closed', () => {

docs/fiddles/quick-start/index.html

@@ -8,9 +8,9 @@
 <body>
     <h1>Hello World!</h1>
     <p>
-        We are using node <script>document.write(process.versions.node)</script>,
-        Chrome <script>document.write(process.versions.chrome)</script>,
-        and Electron <script>document.write(process.versions.electron)</script>.
+        We are using Node.js <span id="node-version"></span>,
+        Chromium <span id="chrome-version"></span>,
+        and Electron <span id="electron-version"></span>.
     </p>
 </body>
 </html>

docs/fiddles/quick-start/main.js

@@ -1,18 +1,27 @@
 const { app, BrowserWindow } = require('electron')
+const path = require('path')
 
 function createWindow () {
   const win = new BrowserWindow({
     width: 800,
     height: 600,
     webPreferences: {
-      nodeIntegration: true
+      preload: path.join(__dirname, 'preload.js')
     }
   })
 
   win.loadFile('index.html')
 }
 
-app.whenReady().then(createWindow)
+app.whenReady().then(() => {
+  createWindow()
+
+  app.on('activate', () => {
+    if (BrowserWindow.getAllWindows().length === 0) {
+      createWindow()
+    }
+  })
+})
 
 app.on('window-all-closed', () => {
   if (process.platform !== 'darwin') {
@@ -20,8 +29,3 @@ app.on('window-all-closed', () => {
   }
 })
 
-app.on('activate', () => {
-  if (BrowserWindow.getAllWindows().length === 0) {
-    createWindow()
-  }
-})

docs/fiddles/quick-start/preload.js

@@ -0,0 +1,11 @@
+window.addEventListener('DOMContentLoaded', () => {
+  const replaceText = (selector, text) => {
+    const element = document.getElementById(selector)
+    if (element) element.innerText = text
+  }
+
+  for (const type of ['chrome', 'node', 'electron']) {
+    replaceText(`${type}-version`, process.versions[type])
+  }
+})
+

docs/styleguide.md

@@ -2,15 +2,14 @@
 
 These are the guidelines for writing Electron documentation.
 
-## Titles
+## Headings
 
 * Each page must have a single `#`-level title at the top.
-* Chapters in the same page must have `##`-level titles.
-* Sub-chapters need to increase the number of `#` in the title according to
+* Chapters in the same page must have `##`-level headings.
+* Sub-chapters need to increase the number of `#` in the heading according to
   their nesting depth.
-* All words in the page's title must be capitalized, except for conjunctions
-  like "of" and "and" .
-* Only the first word of a chapter title must be capitalized.
+* The page's title must follow [APA title case][title-case].
+* All chapters must follow [APA sentence case][sentence-case].
 
 Using `Quick Start` as example:
 
@@ -44,11 +43,20 @@ For API references, there are exceptions to this rule.
 
 ## Markdown rules
 
+This repository uses the [`markdownlint`][markdownlint] package to enforce consistent
+Markdown styling. For the exact rules, see the `.markdownlint.json` file in the root
+folder.
+
+There are a few style guidelines that aren't covered by the linter rules:
+
+<!--TODO(erickzhao): make sure this matches with the lint:markdownlint task-->
 * Use `sh` instead of `cmd` in code blocks (due to the syntax highlighter).
-* Lines should be wrapped at 80 columns.
+* Keep line lengths between 80 and 100 characters if possible for readability
+  purposes.
 * No nesting lists more than 2 levels (due to the markdown renderer).
 * All `js` and `javascript` code blocks are linted with
 [standard-markdown](https://www.npmjs.com/package/standard-markdown).
+* For unordered lists, use asterisks instead of dashes.
 
 ## Picking words
 
@@ -59,14 +67,15 @@ For API references, there are exceptions to this rule.
 
 The following rules only apply to the documentation of APIs.
 
-### Page title
+### Title and description
 
-Each page must use the actual object name returned by `require('electron')`
-as the title, such as `BrowserWindow`, `autoUpdater`, and `session`.
+Each module's API doc must use the actual object name returned by `require('electron')`
+as its title (such as `BrowserWindow`, `autoUpdater`, and `session`).
 
-Under the page title must be a one-line description starting with `>`.
+Directly under the page title, add a one-line description of the module
+as a markdown quote (beginning with `>`).
 
-Using `session` as example:
+Using the `session` module as an example:
 
 ```markdown
 # session
@@ -98,14 +107,19 @@ Using `autoUpdater` as an example:
 * API classes or classes that are part of modules must be listed under a
   `## Class: TheClassName` chapter.
 * One page can have multiple classes.
-* Constructors must be listed with `###`-level titles.
-* [Static Methods](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/static) must be listed under a `### Static Methods` chapter.
-* [Instance Methods](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes#Prototype_methods) must be listed under an `### Instance Methods` chapter.
-* All methods that have a return value must start their description with "Returns `[TYPE]` - Return description"
-  * If the method returns an `Object`, its structure can be specified using a colon followed by a newline then an unordered list of properties in the same style as function parameters.
+* Constructors must be listed with `###`-level headings.
+* [Static Methods](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/static)
+  must be listed under a `### Static Methods` chapter.
+* [Instance Methods](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes#Prototype_methods)
+  must be listed under an `### Instance Methods` chapter.
+* All methods that have a return value must start their description with
+  "Returns `[TYPE]` - [Return description]"
+  * If the method returns an `Object`, its structure can be specified using a colon
+    followed by a newline then an unordered list of properties in the same style as
+    function parameters.
 * Instance Events must be listed under an `### Instance Events` chapter.
 * Instance Properties must be listed under an `### Instance Properties` chapter.
-  * Instance properties must start with "A [Property Type] ..."
+  * Instance Properties must start with "A [Property Type] ..."
 
 Using the `Session` and `Cookies` classes as an example:
 
@@ -141,7 +155,7 @@ Using the `Session` and `Cookies` classes as an example:
 #### `cookies.get(filter, callback)`
 ```
 
-### Methods
+### Methods and their arguments
 
 The methods chapter must be in the following form:
 
@@ -154,8 +168,12 @@ The methods chapter must be in the following form:
 ...
 ```
 
-The title can be `###` or `####`-levels depending on whether it is a method of
-a module or a class.
+#### Heading level
+
+The heading can be `###` or `####`-levels depending on whether the method
+belongs to a module or a class.
+
+#### Function signature
 
 For modules, the `objectName` is the module's name. For classes, it must be the
 name of the instance of the class, and must not be the same as the module's
@@ -164,23 +182,33 @@ name.
 For example, the methods of the `Session` class under the `session` module must
 use `ses` as the `objectName`.
 
-The optional arguments are notated by square brackets `[]` surrounding the optional argument
-as well as the comma required if this optional argument follows another
+Optional arguments are notated by square brackets `[]` surrounding the optional
+argument as well as the comma required if this optional argument follows another
 argument:
 
-```sh
+```markdown
 required[, optional]
 ```
 
-Below the method is more detailed information on each of the arguments. The type
-of argument is notated by either the common types:
+#### Argument descriptions
 
-* [`String`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String)
-* [`Number`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number)
-* [`Object`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object)
-* [`Array`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)
-* [`Boolean`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean)
-* Or a custom type like Electron's [`WebContent`](api/web-contents.md)
+More detailed information on each of the arguments is noted in an unordered list
+below the method. The type of argument is notated by either JavaScript primitives
+(e.g. `String`, `Promise`, or `Object`), a custom API structure like Electron's
+[`Cookie`](api/structures/cookie.md), or the wildcard `any`.
+
+If the argument is of type `Array`, use `[]` shorthand with the type of value
+inside the array (for example,`any[]` or `String[]`).
+
+If the argument is of type `Promise`, parametrize the type with what the promise
+resolves to (for example, `Promise<void>` or `Promise<String>`).
+
+If an argument can be of multiple types, separate the types with `|`.
+
+The description for `Function` type arguments should make it clear how it may be
+called and list the types of the parameters that will be passed to it.
+
+#### Platform-specific functionality
 
 If an argument or a method is unique to certain platforms, those platforms are
 denoted using a space-delimited italicized list following the datatype. Values
@@ -190,12 +218,6 @@ can be `macOS`, `Windows` or `Linux`.
 * `animate` Boolean (optional) _macOS_ _Windows_ - Animate the thing.
 ```
 
-`Array` type arguments must specify what elements the array may include in
-the description below.
-
-The description for `Function` type arguments should make it clear how it may be
-called and list the types of the parameters that will be passed to it.
-
 ### Events
 
 The events chapter must be in following form:
@@ -210,8 +232,8 @@ Returns:
 ...
 ```
 
-The title can be `###` or `####`-levels depending on whether it is an event of
-a module or a class.
+The heading can be `###` or `####`-levels depending on whether the event
+belongs to a module or a class.
 
 The arguments of an event follow the same rules as methods.
 
@@ -225,9 +247,13 @@ The properties chapter must be in following form:
 ...
 ```
 
-The title can be `###` or `####`-levels depending on whether it is a property of
-a module or a class.
+The heading can be `###` or `####`-levels depending on whether the property
+belongs to a module or a class.
 
-## Documentation Translations
+## Documentation translations
 
 See [electron/i18n](https://github.com/electron/i18n#readme)
+
+[title-case]: https://apastyle.apa.org/style-grammar-guidelines/capitalization/title-case
+[sentence-case]: https://apastyle.apa.org/style-grammar-guidelines/capitalization/sentence-case
+[markdownlint]: https://github.com/DavidAnson/markdownlint

docs/tutorial/application-debugging.md

@@ -43,6 +43,6 @@ If the V8 context crashes, the DevTools will display this message.
 
 `DevTools was disconnected from the page. Once page is reloaded, DevTools will automatically reconnect.`
 
-Chromium logs can be enabled via the `ELECTRON_ENABLE_LOGGING` environment variable. For more information, see the [environment variables documentation](https://www.electronjs.org/docs/api/environment-variables#electron_enable_logging).
+Chromium logs can be enabled via the `ELECTRON_ENABLE_LOGGING` environment variable. For more information, see the [environment variables documentation](../api/environment-variables.md#electron_enable_logging).
 
-Alternatively, the command line argument `--enable-logging` can be passed. More information is available in the [command line switches documentation](https://www.electronjs.org/docs/api/command-line-switches#--enable-logging).
+Alternatively, the command line argument `--enable-logging` can be passed. More information is available in the [command line switches documentation](../api/command-line-switches.md#--enable-logging).

docs/tutorial/application-distribution.md

@@ -1,25 +1,38 @@
 # Application Distribution
 
-To distribute your app with Electron, you need to package and rebrand it. The easiest way to do this is to use one of the following third party packaging tools:
+## Overview
+
+To distribute your app with Electron, you need to package and rebrand it.
+To do this, you can either use specialized tooling or manual approaches.
+
+## With tooling
+
+You can use the following tools to distribute your application:
 
 * [electron-forge](https://github.com/electron-userland/electron-forge)
 * [electron-builder](https://github.com/electron-userland/electron-builder)
 * [electron-packager](https://github.com/electron/electron-packager)
 
-These tools will take care of all the steps you need to take to end up with a distributable Electron applications, such as packaging your application, rebranding the executable, setting the right icons and optionally creating installers.
+These tools will take care of all the steps you need to take to end up with a
+distributable Electron application, such as bundling your application,
+rebranding the executable, and setting the right icons.
+
+You can check the example of how to package your app with `electron-forge` in
+our [Quick Start Guide](quick-start.md#package-and-distribute-the-application).
 
 ## Manual distribution
 
-You can also choose to manually get your app ready for distribution. The steps needed to do this are outlined below.
+### With prebuilt binaries
 
-To distribute your app with Electron, you need to download Electron's [prebuilt
+To distribute your app manually, you need to download Electron's [prebuilt
 binaries](https://github.com/electron/electron/releases). Next, the folder
 containing your app should be named `app` and placed in Electron's resources
-directory as shown in the following examples. Note that the location of
-Electron's prebuilt binaries is indicated with `electron/` in the examples
-below.
+directory as shown in the following examples.
 
-On macOS:
+> *NOTE:* the location of Electron's prebuilt binaries is indicated
+with `electron/` in the examples below.
+
+*On macOS:*
 
 ```plaintext
 electron/Electron.app/Contents/Resources/app/
@@ -28,7 +41,7 @@ electron/Electron.app/Contents/Resources/app/
 └── index.html
 ```
 
-On Windows and Linux:
+*On Windows and Linux:*
 
 ```plaintext
 electron/resources/app
@@ -37,47 +50,44 @@ electron/resources/app
 └── index.html
 ```
 
-Then execute `Electron.app` (or `electron` on Linux, `electron.exe` on Windows),
-and Electron will start as your app. The `electron` directory will then be
-your distribution to deliver to final users.
+Then execute `Electron.app` on macOS, `electron` on Linux, or `electron.exe`
+on Windows, and Electron will start as your app. The `electron` directory
+will then be your distribution to deliver to users.
 
-## Packaging Your App into a File
+### With an app source code archive
 
-Apart from shipping your app by copying all of its source files, you can also
-package your app into an [asar](https://github.com/electron/asar) archive to avoid
-exposing your app's source code to users.
+Instead of from shipping your app by copying all of its source files, you can
+package your app into an [asar] archive to improve the performance of reading
+files on platforms like Windows, if you are not already using a bundler such
+as Parcel or Webpack.
 
 To use an `asar` archive to replace the `app` folder, you need to rename the
 archive to `app.asar`, and put it under Electron's resources directory like
 below, and Electron will then try to read the archive and start from it.
 
-On macOS:
+*On macOS:*
 
 ```plaintext
 electron/Electron.app/Contents/Resources/
 └── app.asar
 ```
 
-On Windows and Linux:
+*On Windows and Linux:*
 
 ```plaintext
 electron/resources/
 └── app.asar
 ```
 
-More details can be found in [Application packaging](application-packaging.md).
+You can find more details on how to use `asar` in the
+[`electron/asar` repository][asar].
 
-## Rebranding with Downloaded Binaries
+### Rebranding with downloaded binaries
 
 After bundling your app into Electron, you will want to rebrand Electron
 before distributing it to users.
 
-### Windows
-
-You can rename `electron.exe` to any name you like, and edit its icon and other
-information with tools like [rcedit](https://github.com/electron/rcedit).
-
-### macOS
+#### macOS
 
 You can rename `Electron.app` to any name you want, and you also have to rename
 the `CFBundleDisplayName`, `CFBundleIdentifier` and `CFBundleName` fields in the
@@ -104,60 +114,20 @@ MyApp.app/Contents
             └── MyApp Helper
 ```
 
-### Linux
+#### Windows
+
+You can rename `electron.exe` to any name you like, and edit its icon and other
+information with tools like [rcedit](https://github.com/electron/rcedit).
+
+#### Linux
 
 You can rename the `electron` executable to any name you like.
 
-## Rebranding by Rebuilding Electron from Source
+### Rebranding by rebuilding Electron from source
 
 It is also possible to rebrand Electron by changing the product name and
 building it from source. To do this you need to set the build argument
 corresponding to the product name (`electron_product_name = "YourProductName"`)
 in the `args.gn` file and rebuild.
 
-### Creating a Custom Electron Fork
-
-Creating a custom fork of Electron is almost certainly not something you will
-need to do in order to build your app, even for "Production Level" applications.
-Using a tool such as `electron-packager` or `electron-forge` will allow you to
-"Rebrand" Electron without having to do these steps.
-
-You need to fork Electron when you have custom C++ code that you have patched
-directly into Electron, that either cannot be upstreamed, or has been rejected
-from the official version. As maintainers of Electron, we very much would like
-to make your scenario work, so please try as hard as you can to get your changes
-into the official version of Electron, it will be much much easier on you, and
-we appreciate your help.
-
-#### Creating a Custom Release with surf-build
-
-1. Install [Surf](https://github.com/surf-build/surf), via npm:
-  `npm install -g surf-build@latest`
-
-2. Create a new S3 bucket and create the following empty directory structure:
-
-    ```sh
-    - electron/
-      - symbols/
-      - dist/
-    ```
-
-3. Set the following Environment Variables:
-
-   * `ELECTRON_GITHUB_TOKEN` - a token that can create releases on GitHub
-   * `ELECTRON_S3_ACCESS_KEY`, `ELECTRON_S3_BUCKET`, `ELECTRON_S3_SECRET_KEY` -
-     the place where you'll upload Node.js headers as well as symbols
-   * `ELECTRON_RELEASE` - Set to `true` and the upload part will run, leave unset
-     and `surf-build` will do CI-type checks, appropriate to run for every
-     pull request.
-   * `CI` - Set to `true` or else it will fail
-   * `GITHUB_TOKEN` - set it to the same as `ELECTRON_GITHUB_TOKEN`
-   * `SURF_TEMP` - set to `C:\Temp` on Windows to prevent path too long issues
-   * `TARGET_ARCH` - set to `ia32` or `x64`
-
-4. In `script/upload.py`, you _must_ set `ELECTRON_REPO` to your fork (`MYORG/electron`),
-  especially if you are a contributor to Electron proper.
-
-5. `surf-build -r https://github.com/MYORG/electron -s YOUR_COMMIT -n 'surf-PLATFORM-ARCH'`
-
-6. Wait a very, very long time for the build to complete.
+[asar]: https://github.com/electron/asar

docs/tutorial/application-packaging.md

@@ -1,194 +0,0 @@
-# Application Packaging
-
-To mitigate [issues](https://github.com/joyent/node/issues/6960) around long
-path names on Windows, slightly speed up `require` and conceal your source code
-from cursory inspection, you can choose to package your app into an [asar][asar]
-archive with little changes to your source code.
-
-Most users will get this feature for free, since it's supported out of the box
-by [`electron-packager`][electron-packager], [`electron-forge`][electron-forge],
-and [`electron-builder`][electron-builder]. If you are not using any of these
-tools, read on.
-
-## Generating `asar` Archives
-
-An [asar][asar] archive is a simple tar-like format that concatenates files
-into a single file. Electron can read arbitrary files from it without unpacking
-the whole file.
-
-Steps to package your app into an `asar` archive:
-
-### 1. Install the asar Utility
-
-```sh
-$ npm install -g asar
-```
-
-### 2. Package with `asar pack`
-
-```sh
-$ asar pack your-app app.asar
-```
-
-## Using `asar` Archives
-
-In Electron there are two sets of APIs: Node APIs provided by Node.js and Web
-APIs provided by Chromium. Both APIs support reading files from `asar` archives.
-
-### Node API
-
-With special patches in Electron, Node APIs like `fs.readFile` and `require`
-treat `asar` archives as virtual directories, and the files in it as normal
-files in the filesystem.
-
-For example, suppose we have an `example.asar` archive under `/path/to`:
-
-```sh
-$ asar list /path/to/example.asar
-/app.js
-/file.txt
-/dir/module.js
-/static/index.html
-/static/main.css
-/static/jquery.min.js
-```
-
-Read a file in the `asar` archive:
-
-```javascript
-const fs = require('fs')
-fs.readFileSync('/path/to/example.asar/file.txt')
-```
-
-List all files under the root of the archive:
-
-```javascript
-const fs = require('fs')
-fs.readdirSync('/path/to/example.asar')
-```
-
-Use a module from the archive:
-
-```javascript
-require('./path/to/example.asar/dir/module.js')
-```
-
-You can also display a web page in an `asar` archive with `BrowserWindow`:
-
-```javascript
-const { BrowserWindow } = require('electron')
-const win = new BrowserWindow()
-
-win.loadURL('file:///path/to/example.asar/static/index.html')
-```
-
-### Web API
-
-In a web page, files in an archive can be requested with the `file:` protocol.
-Like the Node API, `asar` archives are treated as directories.
-
-For example, to get a file with `$.get`:
-
-```html
-<script>
-let $ = require('./jquery.min.js')
-$.get('file:///path/to/example.asar/file.txt', (data) => {
-  console.log(data)
-})
-</script>
-```
-
-### Treating an `asar` Archive as a Normal File
-
-For some cases like verifying the `asar` archive's checksum, we need to read the
-content of an `asar` archive as a file. For this purpose you can use the built-in
-`original-fs` module which provides original `fs` APIs without `asar` support:
-
-```javascript
-const originalFs = require('original-fs')
-originalFs.readFileSync('/path/to/example.asar')
-```
-
-You can also set `process.noAsar` to `true` to disable the support for `asar` in
-the `fs` module:
-
-```javascript
-const fs = require('fs')
-process.noAsar = true
-fs.readFileSync('/path/to/example.asar')
-```
-
-## Limitations of the Node API
-
-Even though we tried hard to make `asar` archives in the Node API work like
-directories as much as possible, there are still limitations due to the
-low-level nature of the Node API.
-
-### Archives Are Read-only
-
-The archives can not be modified so all Node APIs that can modify files will not
-work with `asar` archives.
-
-### Working Directory Can Not Be Set to Directories in Archive
-
-Though `asar` archives are treated as directories, there are no actual
-directories in the filesystem, so you can never set the working directory to
-directories in `asar` archives. Passing them as the `cwd` option of some APIs
-will also cause errors.
-
-### Extra Unpacking on Some APIs
-
-Most `fs` APIs can read a file or get a file's information from `asar` archives
-without unpacking, but for some APIs that rely on passing the real file path to
-underlying system calls, Electron will extract the needed file into a
-temporary file and pass the path of the temporary file to the APIs to make them
-work. This adds a little overhead for those APIs.
-
-APIs that requires extra unpacking are:
-
-* `child_process.execFile`
-* `child_process.execFileSync`
-* `fs.open`
-* `fs.openSync`
-* `process.dlopen` - Used by `require` on native modules
-
-### Fake Stat Information of `fs.stat`
-
-The `Stats` object returned by `fs.stat` and its friends on files in `asar`
-archives is generated by guessing, because those files do not exist on the
-filesystem. So you should not trust the `Stats` object except for getting file
-size and checking file type.
-
-### Executing Binaries Inside `asar` Archive
-
-There are Node APIs that can execute binaries like `child_process.exec`,
-`child_process.spawn` and `child_process.execFile`, but only `execFile` is
-supported to execute binaries inside `asar` archive.
-
-This is because `exec` and `spawn` accept `command` instead of `file` as input,
-and `command`s are executed under shell. There is no reliable way to determine
-whether a command uses a file in asar archive, and even if we do, we can not be
-sure whether we can replace the path in command without side effects.
-
-## Adding Unpacked Files to `asar` Archives
-
-As stated above, some Node APIs will unpack the file to the filesystem when
-called. Apart from the performance issues, various anti-virus scanners might
-be triggered by this behavior.
-
-As a workaround, you can leave various files unpacked using the `--unpack` option.
-In the following example, shared libraries of native Node.js modules will not be
-packed:
-
-```sh
-$ asar pack app app.asar --unpack *.node
-```
-
-After running the command, you will notice that a folder named `app.asar.unpacked`
-was created together with the `app.asar` file. It contains the unpacked files
-and should be shipped together with the `app.asar` archive.
-
-[asar]: https://github.com/electron/asar
-[electron-packager]: https://github.com/electron/electron-packager
-[electron-forge]: https://github.com/electron-userland/electron-forge
-[electron-builder]: https://github.com/electron-userland/electron-builder

docs/tutorial/code-signing.md

@@ -189,18 +189,18 @@ You can get a code signing certificate from a lot of resellers. Prices vary, so
 it may be worth your time to shop around. Popular resellers include:
 
 * [digicert](https://www.digicert.com/code-signing/microsoft-authenticode.htm)
-* [Comodo](https://www.comodo.com/landing/ssl-certificate/authenticode-signature/)
+* [Sectigo](https://sectigo.com/ssl-certificates-tls/code-signing)
 * [GoDaddy](https://au.godaddy.com/web-security/code-signing-certificate)
 * Amongst others, please shop around to find one that suits your needs, Google
   is your friend 😄
 
 There are a number of tools for signing your packaged app:
 
-- [`electron-winstaller`] will generate an installer for windows and sign it for
+* [`electron-winstaller`] will generate an installer for windows and sign it for
   you
-- [`electron-forge`] can sign installers it generates through the
+* [`electron-forge`] can sign installers it generates through the
   Squirrel.Windows or MSI targets.
-- [`electron-builder`] can sign some of its windows targets
+* [`electron-builder`] can sign some of its windows targets
 
 ## Windows Store
 

docs/tutorial/dark-mode.md

@@ -19,7 +19,7 @@ the system's dark mode setting. You can do this by using the
 
 If you want to manually switch between light/dark modes, you can do this by
 setting the desired mode in the
-[themeSource](https://www.electronjs.org/docs/api/native-theme#nativethemethemesource)
+[themeSource](../api/native-theme.md#nativethemethemesource)
 property of the `nativeTheme` module. This property's value will be propagated
 to your Renderer process. Any CSS rules related to `prefers-color-scheme` will
 be updated accordingly.
@@ -47,18 +47,18 @@ of this theming, due to the use of the macOS 10.14 SDK.
 
 ## Example
 
-We'll start with a working application from the
-[Quick Start Guide](quick-start.md) and add functionality gradually.
+This example demonstrates an Electron application that derives its theme colors from the
+`nativeTheme`. Additionally, it provides theme toggle and reset controls using IPC channels.
 
-First, let's edit our interface so users can toggle between light and dark
-modes.  This basic UI contains buttons to change the `nativeTheme.themeSource`
-setting and a text element indicating which `themeSource` value is selected.
-By default, Electron follows the system's dark mode preference, so we
-will hardcode the theme source as "System".
+```javascript fiddle='docs/fiddles/features/macos-dark-mode'
 
-Add the following lines to the `index.html` file:
+```
 
-```html
+### How does this work?
+
+Starting with the `index.html` file:
+
+```html title='index.html'
 <!DOCTYPE html>
 <html>
 <head>
@@ -80,65 +80,70 @@ Add the following lines to the `index.html` file:
 </html>
 ```
 
-Next, add [event listeners](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener)
-that listen for `click` events on the toggle buttons. Because the `nativeTheme`
-module only exposed in the Main process, you need to set up each listener's
-callback to use IPC to send messages to and handle responses from the Main
-process:
+And the `style.css` file:
 
-* when the "Toggle Dark Mode" button is clicked, we send the
-`dark-mode:toggle` message (event) to tell the Main process to trigger a theme
-change, and update the "Current Theme Source" label in the UI based on the
-response from the Main process.
-* when the "Reset to System Theme" button is clicked, we send the
-`dark-mode:system` message (event) to tell the Main process to use the system
-color scheme, and update the "Current Theme Source" label to `System`.
+```css title='style.css'
+@media (prefers-color-scheme: dark) {
+  body { background: #333; color: white; }
+}
 
-To add listeners and handlers, add the following lines to the `renderer.js` file:
+@media (prefers-color-scheme: light) {
+  body { background: #ddd; color: black; }
+}
+```
 
-```js
-const { ipcRenderer } = require('electron')
+The example renders an HTML page with a couple elements. The `<strong id="theme-source">`
+ element shows which theme is currently selected, and the two `<button>` elements are the
+ controls. The CSS file uses the [`prefers-color-scheme`][prefers-color-scheme] media query
+ to set the `<body>` element background and text colors.
 
+The `preload.js` script adds a new API to the `window` object called `darkMode`. This API
+ exposes two IPC channels to the renderer process, `'dark-mode:toggle'` and `'dark-mode:system'`.
+ It also assigns two methods, `toggle` and `system`, which pass messages from the renderer to the
+ main process.
+
+```js title='preload.js'
+const { contextBridge, ipcRenderer } = require('electron')
+
+contextBridge.exposeInMainWorld('darkMode', {
+  toggle: () => ipcRenderer.invoke('dark-mode:toggle'),
+  system: () => ipcRenderer.invoke('dark-mode:system')
+})
+```
+
+Now the renderer process can communicate with the main process securely and perform the necessary
+ mutations to the `nativeTheme` object.
+
+The `renderer.js` file is responsible for controlling the `<button>` functionality.
+
+```js title='renderer.js'
 document.getElementById('toggle-dark-mode').addEventListener('click', async () => {
-  const isDarkMode = await ipcRenderer.invoke('dark-mode:toggle')
+  const isDarkMode = await window.darkMode.toggle()
   document.getElementById('theme-source').innerHTML = isDarkMode ? 'Dark' : 'Light'
 })
 
 document.getElementById('reset-to-system').addEventListener('click', async () => {
-  await ipcRenderer.invoke('dark-mode:system')
+  await window.darkMode.system()
   document.getElementById('theme-source').innerHTML = 'System'
 })
 ```
 
-If you run your code at this point, you'll see that your buttons don't do
-anything just yet, and your Main process will output an error like this when
-you click on your buttons:
-`Error occurred in handler for 'dark-mode:toggle': No handler registered for 'dark-mode:toggle'`
-This is expected — we haven't actually touched any `nativeTheme` code yet.
+Using `addEventListener`, the `renderer.js` file adds `'click'` [event listeners][event-listeners]
+ to each button element. Each event listener handler makes calls to the respective `window.darkMode`
+ API methods.
 
-Now that we're done wiring the IPC from the Renderer's side, the next step
-is to update the `main.js` file to handle events from the Renderer process.
-
-Depending on the received event, we update the
-[`nativeTheme.themeSource`](../api/native-theme.md#nativethemethemesource)
-property to apply the desired theme on the system's native UI elements
-(e.g. context menus) and propagate the preferred color scheme to the Renderer
-process:
-
-* Upon receiving `dark-mode:toggle`, we check if the dark theme is currently
-active using the `nativeTheme.shouldUseDarkColors` property, and set the
-`themeSource` to the opposite theme.
-* Upon receiving `dark-mode:system`, we reset the `themeSource` to `system`.
+Finally, the `main.js` file represents the main process and contains the actual `nativeTheme` API.
 
 ```js
 const { app, BrowserWindow, ipcMain, nativeTheme } = require('electron')
+const path = require('path')
 
 function createWindow () {
   const win = new BrowserWindow({
     width: 800,
     height: 600,
     webPreferences: {
-      nodeIntegration: true
+      preload: path.join(__dirname, 'preload.js')
     }
   })
 
@@ -158,40 +163,37 @@ function createWindow () {
   })
 }
 
-app.whenReady().then(createWindow)
+app.whenReady().then(() => {
+  createWindow()
+
+  app.on('activate', () => {
+    if (BrowserWindow.getAllWindows().length === 0) {
+      createWindow()
+    }
+  })
+})
 
 app.on('window-all-closed', () => {
   if (process.platform !== 'darwin') {
     app.quit()
   }
 })
-
-app.on('activate', () => {
-  if (BrowserWindow.getAllWindows().length === 0) {
-    createWindow()
-  }
-})
 ```
 
-The final step is to add a bit of styling to enable dark mode for the web parts
-of the UI by leveraging the [`prefers-color-scheme`][prefer-color-scheme] CSS
-attribute. The value of `prefers-color-scheme` will follow your
-`nativeTheme.themeSource` setting.
+The `ipcMain.handle` methods are how the main process responds to the click events from the buttons
+ on the HTML page.
 
-Create a `styles.css` file and add the following lines:
+The `'dark-mode:toggle'` IPC channel handler method checks the `shouldUseDarkColors` boolean property,
+ sets the corresponding `themeSource`, and then returns the current `shouldUseDarkColors` property.
+ Looking back on the renderer process event listener for this IPC channel, the return value from this
+ handler is utilized to assign the correct text to the `<strong id='theme-source'>` element.
 
-```css
-@media (prefers-color-scheme: dark) {
-  body { background:  #333; color: white; }
-}
+The `'dark-mode:system'` IPC channel handler method assigns the string `'system'` to the `themeSource`
+ and returns nothing. This also corresponds with the relative renderer process event listener as the
+ method is awaited with no return value expected.
 
-@media (prefers-color-scheme: light) {
-  body { background:  #ddd; color: black; }
-}
-```
-
-After launching the Electron application, you can change modes or reset the
-theme to system default by clicking corresponding buttons:
+Run the example using Electron Fiddle and then click the "Toggle Dark Mode" button; the app should
+ start alternating between a light and dark background color.
 
 ![Dark Mode](../images/dark_mode.gif)
 
@@ -199,4 +201,5 @@ theme to system default by clicking corresponding buttons:
 [electron-forge]: https://www.electronforge.io/
 [electron-packager]: https://github.com/electron/electron-packager
 [packager-darwindarkmode-api]: https://electron.github.io/electron-packager/master/interfaces/electronpackager.options.html#darwindarkmodesupport
-[prefer-color-scheme]: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme
+[prefers-color-scheme]: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme
+[event-listeners]: https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener

docs/tutorial/debugging-vscode.md

@@ -35,7 +35,6 @@ $ code electron-quick-start
 }
 ```
 
-
 #### 3. Debugging
 
 Set some breakpoints in `main.js`, and start debugging in the [Debug View](https://code.visualstudio.com/docs/editor/debugging). You should be able to hit the breakpoints.
@@ -84,16 +83,16 @@ $ code electron-quick-start
   ]
 }
 ```
+
 **Configuration Notes**
 
-- `cppvsdbg` requires the [built-in C/C++ extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools) be enabled.
-- `${workspaceFolder}` is the full path to Chromium's `src` directory.
-- `your-executable-location` will be one of the following depending on a few items:
-  -  `Testing`: If you are using the default settings of [Electron's Build-Tools](https://github.com/electron/build-tools) or the default instructions when [building from source](https://www.electronjs.org/docs/development/build-instructions-gn#building).
-  -  `Release`: If you built a Release build rather than a Testing build.
-  -  `your-directory-name`: If you modified this during your build process from the default, this will be whatever you specified.
-- The `args` array string `"your-electron-project-path"` should be the absolute path to either the directory or `main.js` file of the Electron project you are using for testing. In this example, it should be your path to `electron-quick-start`.
-
+* `cppvsdbg` requires the [built-in C/C++ extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools) be enabled.
+* `${workspaceFolder}` is the full path to Chromium's `src` directory.
+* `your-executable-location` will be one of the following depending on a few items:
+  * `Testing`: If you are using the default settings of [Electron's Build-Tools](https://github.com/electron/build-tools) or the default instructions when [building from source](https://www.electronjs.org/docs/development/build-instructions-gn#building).
+  * `Release`: If you built a Release build rather than a Testing build.
+  * `your-directory-name`: If you modified this during your build process from the default, this will be whatever you specified.
+* The `args` array string `"your-electron-project-path"` should be the absolute path to either the directory or `main.js` file of the Electron project you are using for testing. In this example, it should be your path to `electron-quick-start`.
 
 #### 3. Debugging
 

docs/tutorial/devtools-extension.md

@@ -32,6 +32,7 @@ Using the [React Developer Tools][react-devtools] as an example:
    * on macOS it is `~/Library/Application Support/Google/Chrome/Default/Extensions`.
 1. Pass the location of the extension to the [`ses.loadExtension`][load-extension]
    API. For React Developer Tools `v4.9.0`, it looks something like:
+
    ```javascript
     const { app, session } = require('electron')
     const path = require('path')
@@ -96,7 +97,7 @@ of the extension is not working as expected.
 [devtools-extension]: https://developer.chrome.com/extensions/devtools
 [session]: ../api/session.md
 [react-devtools]: https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi
-[load-extension]: ../api/session.md#sesloadextensionpath
+[load-extension]: ../api/session.md#sesloadextensionpath-options
 [extension-structure]: ../api/structures/extension.md
 [remove-extension]: ../api/session.md#sesremoveextensionextensionid
 [electron-devtools-installer]: https://github.com/MarshallOfSound/electron-devtools-installer

docs/tutorial/electron-timelines.md

@@ -18,4 +18,5 @@
 | 9.0.0 | 2020-02-06 | 2020-05-19 | M83 | v12.14 |
 | 10.0.0 | 2020-05-21 | 2020-08-25 | M85 | v12.16 |
 | 11.0.0 | 2020-08-27 | 2020-11-17 | M87 | v12.18 |
-| 12.0.0 | 2020-11-19 | 2021-03-02 | M89 | v14.x |
+| 12.0.0 | 2020-11-19 | 2021-03-02 | M89 | v14.16 |
+| 13.0.0 | 2021-03-04 | 2021-05-25 | M91 | v14.x |

docs/tutorial/electron-versioning.md

@@ -2,7 +2,7 @@
 
 > A detailed look at our versioning policy and implementation.
 
-As of version 2.0.0, Electron follows [semver](#semver). The following command will install the most recent stable build of Electron:
+As of version 2.0.0, Electron follows [SemVer](#semver). The following command will install the most recent stable build of Electron:
 
 ```sh
 npm install --save-dev electron
@@ -16,11 +16,11 @@ npm install --save-dev electron@latest
 
 ## Version 1.x
 
-Electron versions *< 2.0* did not conform to the [semver](https://semver.org) spec: major versions corresponded to end-user API changes, minor versions corresponded to Chromium major releases, and patch versions corresponded to new features and bug fixes. While convenient for developers merging features, it creates problems for developers of client-facing applications. The QA testing cycles of major apps like Slack, Stride, Teams, Skype, VS Code, Atom, and Desktop can be lengthy and stability is a highly desired outcome. There is a high risk in adopting new features while trying to absorb bug fixes.
+Electron versions *< 2.0* did not conform to the [SemVer](https://semver.org) spec: major versions corresponded to end-user API changes, minor versions corresponded to Chromium major releases, and patch versions corresponded to new features and bug fixes. While convenient for developers merging features, it creates problems for developers of client-facing applications. The QA testing cycles of major apps like Slack, Stride, Teams, Skype, VS Code, Atom, and Desktop can be lengthy and stability is a highly desired outcome. There is a high risk in adopting new features while trying to absorb bug fixes.
 
 Here is an example of the 1.x strategy:
 
-![](../images/versioning-sketch-0.png)
+![1.x Versioning](../images/versioning-sketch-0.png)
 
 An app developed with `1.8.1` cannot take the `1.8.3` bug fix without either absorbing the `1.8.2` feature, or by backporting the fix and maintaining a new release line.
 
@@ -28,7 +28,7 @@ An app developed with `1.8.1` cannot take the `1.8.3` bug fix without either abs
 
 There are several major changes from our 1.x strategy outlined below. Each change is intended to satisfy the needs and priorities of developers/maintainers and app developers.
 
-1. Strict use of semver
+1. Strict use of SemVer
 2. Introduction of semver-compliant `-beta` tags
 3. Introduction of [conventional commit messages](https://conventionalcommits.org/)
 4. Well-defined stabilization branches
@@ -36,11 +36,11 @@ There are several major changes from our 1.x strategy outlined below. Each chang
 
 We will cover in detail how git branching works, how npm tagging works, what developers should expect to see, and how one can backport changes.
 
-# semver
+# SemVer
 
-From 2.0 onward, Electron will follow semver.
+From 2.0 onward, Electron will follow SemVer.
 
-Below is a table explicitly mapping types of changes to their corresponding category of semver (e.g. Major, Minor, Patch).
+Below is a table explicitly mapping types of changes to their corresponding category of SemVer (e.g. Major, Minor, Patch).
 
 | Major Version Increments        | Minor Version Increments           | Patch Version Increments      |
 | ------------------------------- | ---------------------------------- | ----------------------------- |
@@ -54,12 +54,12 @@ Note that most Chromium updates will be considered breaking. Fixes that can be b
 
 Stabilization branches are branches that run parallel to master, taking in only cherry-picked commits that are related to security or stability. These branches are never merged back to master.
 
-![](../images/versioning-sketch-1.png)
+![Stabilization Branches](../images/versioning-sketch-1.png)
 
 Since Electron 8, stabilization branches are always **major** version lines, and named against the following template `$MAJOR-x-y` e.g. `8-x-y`.  Prior to that we used **minor** version lines and named them as `$MAJOR-$MINOR-x` e.g. `2-0-x`
 
 We allow for multiple stabilization branches to exist simultaneously, and intend to support at least two in parallel at all times, backporting security fixes as necessary.
-![](../images/versioning-sketch-2.png)
+![Multiple Stability Branches](../images/versioning-sketch-2.png)
 
 Older lines will not be supported by GitHub, but other groups can take ownership and backport stability and security fixes on their own. We discourage this, but recognize that it makes life easier for many app developers.
 
@@ -70,13 +70,13 @@ Developers want to know which releases are _safe_ to use. Even seemingly innocen
 * Use `~2.0.0` to admit only stability or security related fixes to your `2.0.0` release.
 * Use `^2.0.0` to admit non-breaking _reasonably stable_ feature work as well as security and bug fixes.
 
-What’s important about the second point is that apps using `^` should still be able to expect a reasonable level of stability. To accomplish this, semver allows for a _pre-release identifier_ to indicate a particular version is not yet _safe_ or _stable_.
+What’s important about the second point is that apps using `^` should still be able to expect a reasonable level of stability. To accomplish this, SemVer allows for a _pre-release identifier_ to indicate a particular version is not yet _safe_ or _stable_.
 
 Whatever you choose, you will periodically have to bump the version in your `package.json` as breaking changes are a fact of Chromium life.
 
 The process is as follows:
 
-1. All new major and minor releases lines begin with a beta series indicated by semver prerelease tags of `beta.N`, e.g. `2.0.0-beta.1`. After the first beta, subsequent beta releases must meet all of the following conditions:
+1. All new major and minor releases lines begin with a beta series indicated by SemVer prerelease tags of `beta.N`, e.g. `2.0.0-beta.1`. After the first beta, subsequent beta releases must meet all of the following conditions:
     1. The change is backwards API-compatible (deprecations are allowed)
     2. The risk to meeting our stability timeline must be low.
 2. If allowed changes need to be made once a release is beta, they are applied and the prerelease tag is incremented, e.g. `2.0.0-beta.2`.
@@ -86,7 +86,7 @@ e.g. `2.0.1`.
 
 Specifically, the above means:
 
-1. Admitting non-breaking-API changes before Week 3 in the beta cycle is okay, even if those changes have the potential to cause moderate side-effects
+1. Admitting non-breaking-API changes before Week 3 in the beta cycle is okay, even if those changes have the potential to cause moderate side-effects.
 2. Admitting feature-flagged changes, that do not otherwise alter existing code paths, at most points in the beta cycle is okay. Users can explicitly enable those flags in their apps.
 3. Admitting features of any sort after Week 3 in the beta cycle is 👎 without a very good reason.
 
@@ -104,17 +104,17 @@ For each major and minor bump, you should expect to see something like the follo
 An example lifecycle in pictures:
 
 * A new release branch is created that includes the latest set of features. It is published as `2.0.0-beta.1`.
-![](../images/versioning-sketch-3.png)
+![New Release Branch](../images/versioning-sketch-3.png)
 * A bug fix comes into master that can be backported to the release branch. The patch is applied, and a new beta is published as `2.0.0-beta.2`.
-![](../images/versioning-sketch-4.png)
+![Bugfix Backport to Beta](../images/versioning-sketch-4.png)
 * The beta is considered _generally stable_ and it is published again as a non-beta under `2.0.0`.
-![](../images/versioning-sketch-5.png)
+![Beta to Stable](../images/versioning-sketch-5.png)
 * Later, a zero-day exploit is revealed and a fix is applied to master. We backport the fix to the `2-0-x` line and release `2.0.1`.
-![](../images/versioning-sketch-6.png)
+![Security Backports](../images/versioning-sketch-6.png)
 
-A few examples of how various semver ranges will pick up new releases:
+A few examples of how various SemVer ranges will pick up new releases:
 
-![](../images/versioning-sketch-7.png)
+![Semvers and Releases](../images/versioning-sketch-7.png)
 
 # Missing Features: Alphas
 
@@ -136,16 +136,16 @@ Feature flags are a common practice in Chromium, and are well-established in the
 
 We seek to increase clarity at all levels of the update and releases process. Starting with `2.0.0` we will require pull requests adhere to the [Conventional Commits](https://conventionalcommits.org/) spec, which can be summarized as follows:
 
-* Commits that would result in a semver **major** bump must start their body with `BREAKING CHANGE:`.
-* Commits that would result in a semver **minor** bump must start with `feat:`.
-* Commits that would result in a semver **patch** bump must start with `fix:`.
+* Commits that would result in a SemVer **major** bump must start their body with `BREAKING CHANGE:`.
+* Commits that would result in a SemVer **minor** bump must start with `feat:`.
+* Commits that would result in a SemVer **patch** bump must start with `fix:`.
 
 * We allow squashing of commits, provided that the squashed message adheres to the above message format.
 * It is acceptable for some commits in a pull request to not include a semantic prefix, as long as the pull request title contains a meaningful encompassing semantic message.
 
 # Versioned `master`
 
-- The `master` branch will always contain the next major version `X.0.0-nightly.DATE` in its `package.json`
-- Release branches are never merged back to master
-- Release branches _do_ contain the correct version in their `package.json`
-- As soon as a release branch is cut for a major, master must be bumped to the next major.  I.e. `master` is always versioned as the next theoretical release branch
+* The `master` branch will always contain the next major version `X.0.0-nightly.DATE` in its `package.json`
+* Release branches are never merged back to master
+* Release branches _do_ contain the correct version in their `package.json`
+* As soon as a release branch is cut for a major, master must be bumped to the next major.  I.e. `master` is always versioned as the next theoretical release branch

docs/tutorial/installation.md

@@ -11,14 +11,19 @@ npm install electron --save-dev
 See the [Electron versioning doc][versioning] for info on how to
 manage Electron versions in your apps.
 
-## Global Installation
+## Running Electron ad-hoc
 
-You can also install the `electron` command globally in your `$PATH`:
+If you're in a pinch and would prefer to not use `npm install` in your local
+project, you can also run Electron ad-hoc using the [`npx`][npx] command runner
+bundled with `npm`:
 
 ```sh
-npm install electron -g
+npx electron .
 ```
 
+The above command will run the current working directory with Electron. Note that
+any dependencies in your app will not be installed.
+
 ## Customization
 
 If you want to change the architecture that is downloaded (e.g., `ia32` on an
@@ -178,6 +183,7 @@ If you need to force a re-download of the asset and the SHASUM file set the
 
 [npm]: https://docs.npmjs.com
 [versioning]: ./electron-versioning.md
+[npx]: https://docs.npmjs.com/cli/v7/commands/npx
 [releases]: https://github.com/electron/electron/releases
 [proxy-env-10]: https://github.com/gajus/global-agent/blob/v2.1.5/README.md#environment-variables
 [proxy-env]: https://github.com/np-maintain/global-tunnel/blob/v2.7.1/README.md#auto-config

docs/tutorial/keyboard-shortcuts.md

@@ -17,7 +17,7 @@ Starting with a working application from the
 [Quick Start Guide](quick-start.md), update the `main.js` file with the
 following lines:
 
-```js
+```javascript fiddle='docs/fiddles/features/keyboard-shortcuts/local'
 const { Menu, MenuItem } = require('electron')
 
 const menu = new Menu()
@@ -56,7 +56,7 @@ Starting with a working application from the
 [Quick Start Guide](quick-start.md), update the `main.js` file with the
 following lines:
 
-```js
+```javascript fiddle='docs/fiddles/features/keyboard-shortcuts/global'
 const { app, globalShortcut } = require('electron')
 
 app.whenReady().then(() => {
@@ -101,7 +101,7 @@ Starting with a working application from the
 [Quick Start Guide](quick-start.md), update the `main.js` file with the
 following lines:
 
-```js
+```javascript fiddle='docs/fiddles/features/keyboard-shortcuts/interception-from-main'
 const { app, BrowserWindow } = require('electron')
 
 app.whenReady().then(() => {

docs/tutorial/mac-app-store-submission-guide.md

@@ -1,53 +1,111 @@
 # Mac App Store Submission Guide
 
-Since v0.34.0, Electron allows submitting packaged apps to the Mac App Store
-(MAS). This guide provides information on: how to submit your app and the
-limitations of the MAS build.
+This guide provides information on:
 
-**Note:** Submitting an app to Mac App Store requires enrolling in the [Apple Developer
-Program][developer-program], which costs money.
+* How to sign Electron apps on macOS;
+* How to submit Electron apps to Mac App Store (MAS);
+* The limitations of the MAS build.
 
-## How to Submit Your App
+## Requirements
 
-The following steps introduce a simple way to submit your app to Mac App Store.
-However, these steps do not ensure your app will be approved by Apple; you
-still need to read Apple's [Submitting Your App][submitting-your-app] guide on
-how to meet the Mac App Store requirements.
+To sign Electron apps, the following tools must be installed first:
 
-### Get Certificate
+* Xcode 11 or above.
+* The [electron-osx-sign][electron-osx-sign] npm module.
 
-To submit your app to the Mac App Store, you first must get a certificate from
-Apple. You can follow these [existing guides][nwjs-guide] on web.
+You also have to register an Apple Developer account and join the
+[Apple Developer Program][developer-program].
 
-### Get Team ID
+## Sign Electron apps
 
-Before signing your app, you need to know the Team ID of your account. To locate
-your Team ID, Sign in to [Apple Developer Center](https://developer.apple.com/account/),
-and click Membership in the sidebar. Your Team ID appears in the Membership
-Information section under the team name.
+Electron apps can be distributed through Mac App Store or outside it. Each way
+requires different ways of signing and testing. This guide focuses on
+distribution via Mac App Store, but will also mention other methods.
 
-### Sign Your App
+The following steps describe how to get the certificates from Apple, how to sign
+Electron apps, and how to test them.
 
-After finishing the preparation work, you can package your app by following
-[Application Distribution](application-distribution.md), and then proceed to
-signing your app.
+### Get certificates
 
-First, you have to add a `ElectronTeamID` key to your app's `Info.plist`, which
-has your Team ID as its value:
+The simplest way to get signing certificates is to use Xcode:
 
-```xml
-<plist version="1.0">
-<dict>
-  ...
-  <key>ElectronTeamID</key>
-  <string>TEAM_ID</string>
-</dict>
-</plist>
-```
+1. Open Xcode and open "Accounts" preferences;
+2. Sign in with your Apple account;
+3. Select a team and click "Manage Certificates";
+4. In the lower-left corner of the signing certificates sheet, click the Add
+   button (+), and add following certificates:
+   * "Apple Development"
+   * "Apple Distribution"
 
-Then, you need to prepare three entitlements files.
+The "Apple Development" certificate is used to sign apps for development and
+testing, on machines that have been registered on Apple Developer website. The
+method of registration will be described in
+[Prepare provisioning profile](#prepare-provisioning-profile).
 
-`child.plist`:
+Apps signed with the "Apple Development" certificate cannot be submitted to Mac
+App Store. For that purpose, apps must be signed with the "Apple Distribution"
+certificate instead. But note that apps signed with the "Apple Distribution"
+certificate cannot run directly, they must be re-signed by Apple to be able to
+run, which will only be possible after being downloaded from the Mac App Store.
+
+#### Other certificates
+
+You may notice that there are also other kinds of certificates.
+
+The "Developer ID Application" certificate is used to sign apps before
+distributing them outside the Mac App Store.
+
+The "Developer ID Installer" and "Mac Installer Distribution" certificates are
+used to sign the Mac Installer Package instead of the app itself. Most Electron
+apps do not use Mac Installer Package so they are generally not needed.
+
+The full list of certificate types can be found
+[here](https://help.apple.com/xcode/mac/current/#/dev80c6204ec).
+
+Apps signed with "Apple Development" and "Apple Distribution" certificates can
+only run under [App Sandbox][app-sandboxing], so they must use the MAS build of
+Electron. However, the "Developer ID Application" certificate does not have this
+restrictions, so apps signed with it can use either the normal build or the MAS
+build of Electron.
+
+#### Legacy certificate names
+
+Apple has been changing the names of certificates during past years, you might
+encounter them when reading old documentations, and some utilities are still
+using one of the old names.
+
+* The "Apple Distribution" certificate was also named as "3rd Party Mac
+  Developer Application" and "Mac App Distribution".
+* The "Apple Development" certificate was also named as "Mac Developer" and
+  "Development".
+
+### Prepare provisioning profile
+
+If you want to test your app on your local machine before submitting your app to
+the Mac App Store, you have to sign the app with the "Apple Development"
+certificate with the provisioning profile embedded in the app bundle.
+
+To [create a provisioning profile](https://help.apple.com/developer-account/#/devf2eb157f8),
+you can follow the below steps:
+
+1. Open the "Certificates, Identifiers & Profiles" page on the
+   [Apple Developer](https://developer.apple.com/account) website.
+2. Add a new App ID for your app in the "Identifiers" page.
+3. Register your local machine in the "Devices" page. You can find your
+   machine's "Device ID" in the "Hardware" page of the "System Information" app.
+4. Register a new Provisioning Profile in the "Profiles" page, and download it
+   to `/path/to/yourapp.provisionprofile`.
+
+### Enable Apple's App Sandbox
+
+Apps submitted to the Mac App Store must run under Apple's
+[App Sandbox][app-sandboxing], and only the MAS build of Electron can run with
+the App Sandbox. The standard darwin build of Electron will fail to launch
+when run under App Sandbox.
+
+When signing the app with `electron-osx-sign`, it will automatically add the
+necessary entitlements to your app's entitlements, but if you are using custom
+entitlements, you must ensure App Sandbox capacity is added:
 
 ```xml
 <?xml version="1.0" encoding="UTF-8"?>
@@ -56,13 +114,14 @@ Then, you need to prepare three entitlements files.
   <dict>
     <key>com.apple.security.app-sandbox</key>
     <true/>
-    <key>com.apple.security.inherit</key>
-    <true/>
   </dict>
 </plist>
 ```
 
-`parent.plist`:
+#### Extra steps without `electron-osx-sign`
+
+If you are signing your app without using `electron-osx-sign`, you must ensure
+the app bundle's entitlements have at least following keys:
 
 ```xml
 <?xml version="1.0" encoding="UTF-8"?>
@@ -79,7 +138,11 @@ Then, you need to prepare three entitlements files.
 </plist>
 ```
 
-`loginhelper.plist`:
+The `TEAM_ID` should be replaced with your Apple Developer account's Team ID,
+and the `your.bundle.id` should be replaced with the App ID of the app.
+
+And the following entitlements must be added to the binaries and helpers in
+the app's bundle:
 
 ```xml
 <?xml version="1.0" encoding="UTF-8"?>
@@ -88,80 +151,97 @@ Then, you need to prepare three entitlements files.
   <dict>
     <key>com.apple.security.app-sandbox</key>
     <true/>
+    <key>com.apple.security.inherit</key>
+    <true/>
   </dict>
 </plist>
 ```
 
-You have to replace `TEAM_ID` with your Team ID, and replace `your.bundle.id`
-with the Bundle ID of your app.
+And the app bundle's `Info.plist` must include `ElectronTeamID` key, which has
+your Apple Developer account's Team ID as its value:
 
-And then sign your app with the following script:
-
-```sh
-#!/bin/bash
-
-# Name of your app.
-APP="YourApp"
-# The path of your app to sign.
-APP_PATH="/path/to/YourApp.app"
-# The path to the location you want to put the signed package.
-RESULT_PATH="~/Desktop/$APP.pkg"
-# The name of certificates you requested.
-APP_KEY="3rd Party Mac Developer Application: Company Name (APPIDENTITY)"
-INSTALLER_KEY="3rd Party Mac Developer Installer: Company Name (APPIDENTITY)"
-# The path of your plist files.
-CHILD_PLIST="/path/to/child.plist"
-PARENT_PLIST="/path/to/parent.plist"
-LOGINHELPER_PLIST="/path/to/loginhelper.plist"
-
-FRAMEWORKS_PATH="$APP_PATH/Contents/Frameworks"
-
-codesign -s "$APP_KEY" -f --entitlements "$CHILD_PLIST" "$FRAMEWORKS_PATH/Electron Framework.framework/Versions/A/Electron Framework"
-codesign -s "$APP_KEY" -f --entitlements "$CHILD_PLIST" "$FRAMEWORKS_PATH/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib"
-codesign -s "$APP_KEY" -f --entitlements "$CHILD_PLIST" "$FRAMEWORKS_PATH/Electron Framework.framework/Versions/A/Libraries/libnode.dylib"
-codesign -s "$APP_KEY" -f --entitlements "$CHILD_PLIST" "$FRAMEWORKS_PATH/Electron Framework.framework"
-codesign -s "$APP_KEY" -f --entitlements "$CHILD_PLIST" "$FRAMEWORKS_PATH/$APP Helper.app/Contents/MacOS/$APP Helper"
-codesign -s "$APP_KEY" -f --entitlements "$CHILD_PLIST" "$FRAMEWORKS_PATH/$APP Helper.app/"
-codesign -s "$APP_KEY" -f --entitlements "$LOGINHELPER_PLIST" "$APP_PATH/Contents/Library/LoginItems/$APP Login Helper.app/Contents/MacOS/$APP Login Helper"
-codesign -s "$APP_KEY" -f --entitlements "$LOGINHELPER_PLIST" "$APP_PATH/Contents/Library/LoginItems/$APP Login Helper.app/"
-codesign -s "$APP_KEY" -f --entitlements "$CHILD_PLIST" "$APP_PATH/Contents/MacOS/$APP"
-codesign -s "$APP_KEY" -f --entitlements "$PARENT_PLIST" "$APP_PATH"
-
-productbuild --component "$APP_PATH" /Applications --sign "$INSTALLER_KEY" "$RESULT_PATH"
+```xml
+<plist version="1.0">
+<dict>
+  ...
+  <key>ElectronTeamID</key>
+  <string>TEAM_ID</string>
+</dict>
+</plist>
 ```
 
-If you are new to app sandboxing under macOS, you should also read through
-Apple's [Enabling App Sandbox][enable-app-sandbox] to have a basic idea, then
-add keys for the permissions needed by your app to the entitlements files.
+When using `electron-osx-sign` the `ElectronTeamID` key will be added
+automatically by extracting the Team ID from the certificate's name. You may
+need to manually add this key if `electron-osx-sign` could not find the correct
+Team ID.
 
-Apart from manually signing your app, you can also choose to use the
-[electron-osx-sign][electron-osx-sign] module to do the job.
+### Sign apps for development
 
-#### Sign Native Modules
+To sign an app that can run on your development machine, you must sign it with
+the "Apple Development" certificate and pass the provisioning profile to
+`electron-osx-sign`.
 
-Native modules used in your app also need to be signed. If using
-electron-osx-sign, be sure to include the path to the built binaries in the
-argument list:
-
-```sh
-electron-osx-sign YourApp.app YourApp.app/Contents/Resources/app/node_modules/nativemodule/build/release/nativemodule
+```bash
+electron-osx-sign YourApp.app --identity='Apple Development' --provisioning-profile=/path/to/yourapp.provisionprofile
 ```
 
-Also note that native modules may have intermediate files produced which should
-not be included (as they would also need to be signed). If you use
-[electron-packager][electron-packager] before version 8.1.0, add
-`--ignore=.+\.o$` to your build step to ignore these files. Versions 8.1.0 and
-later ignore those files by default.
+If you are signing without `electron-osx-sign`, you must place the provisioning
+profile to `YourApp.app/Contents/embedded.provisionprofile`.
 
-### Upload Your App
+The signed app can only run on the machines that registered by the provisioning
+profile, and this is the only way to test the signed app before submitting to
+Mac App Store.
 
-After signing your app, you can use Application Loader to upload it to iTunes
+### Sign apps for submitting to the Mac App Store
+
+To sign an app that will be submitted to Mac App Store, you must sign it with
+the "Apple Distribution" certificate. Note that apps signed with this
+certificate will not run anywhere, unless it is downloaded from Mac App Store.
+
+```bash
+electron-osx-sign YourApp.app --identity='Apple Distribution'
+```
+
+### Sign apps for distribution outside the Mac App Store
+
+If you don't plan to submit the app to Mac App Store, you can sign it the
+"Developer ID Application" certificate. In this way there is no requirement on
+App Sandbox, and you should use the normal darwin build of Electron if you don't
+use App Sandbox.
+
+```bash
+electron-osx-sign YourApp.app --identity='Developer ID Application' --no-gatekeeper-assess
+```
+
+By passing `--no-gatekeeper-assess`, the `electron-osx-sign` will skip the macOS
+GateKeeper check as your app usually has not been notarized yet by this step.
+
+<!-- TODO(zcbenz): Add a chapter about App Notarization -->
+This guide does not cover [App Notarization][app-notarization], but you might
+want to do it otherwise Apple may prevent users from using your app outside Mac
+App Store.
+
+## Submit Apps to the Mac App Store
+
+After signing the app with the "Apple Distribution" certificate, you can
+continue to submit it to Mac App Store.
+
+However, this guide do not ensure your app will be approved by Apple; you
+still need to read Apple's [Submitting Your App][submitting-your-app] guide on
+how to meet the Mac App Store requirements.
+
+### Upload
+
+The Application Loader should be used to upload the signed app to iTunes
 Connect for processing, making sure you have [created a record][create-record]
 before uploading.
 
-### Submit Your App for Review
+If you are seeing errors like private APIs uses, you should check if the app is
+using the MAS build of Electron.
 
-After these steps, you can [submit your app for review][submit-for-review].
+### Submit for review
+
+After uploading, you should [submit your app for review][submit-for-review].
 
 ## Limitations of MAS Build
 
@@ -181,13 +261,13 @@ Also, due to the usage of app sandboxing, the resources which can be accessed by
 the app are strictly limited; you can read [App Sandboxing][app-sandboxing] for
 more information.
 
-### Additional Entitlements
+### Additional entitlements
 
 Depending on which Electron APIs your app uses, you may need to add additional
-entitlements to your `parent.plist` file to be able to use these APIs from your
-app's Mac App Store build.
+entitlements to your app's entitlements file. Otherwise, the App Sandbox may
+prevent you from using them.
 
-#### Network Access
+#### Network access
 
 Enable outgoing network connections to allow your app to connect to a server:
 
@@ -261,15 +341,12 @@ Electron uses following cryptographic algorithms:
 * RIPEMD - [ISO/IEC 10118-3](https://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2FIEC%2010118-3:2004)
 
 [developer-program]: https://developer.apple.com/support/compare-memberships/
-[submitting-your-app]: https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDistributionGuide/SubmittingYourApp/SubmittingYourApp.html
-[nwjs-guide]: https://github.com/nwjs/nw.js/wiki/Mac-App-Store-%28MAS%29-Submission-Guideline#first-steps
-[enable-app-sandbox]: https://developer.apple.com/library/ios/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html
-[create-record]: https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/CreatingiTunesConnectRecord.html
-[electron-osx-sign]: https://github.com/electron-userland/electron-osx-sign
-[electron-packager]: https://github.com/electron/electron-packager
-[submit-for-review]: https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/SubmittingTheApp.html
+[electron-osx-sign]: https://github.com/electron/electron-osx-sign
 [app-sandboxing]: https://developer.apple.com/app-sandboxing/
+[app-notarization]: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
+[submitting-your-app]: https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDistributionGuide/SubmittingYourApp/SubmittingYourApp.html
+[create-record]: https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/CreatingiTunesConnectRecord.html
+[submit-for-review]: https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/SubmittingTheApp.html
 [export-compliance]: https://help.apple.com/app-store-connect/#/devc3f64248f
-[temporary-exception]: https://developer.apple.com/library/mac/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AppSandboxTemporaryExceptionEntitlements.html
 [user-selected]: https://developer.apple.com/library/mac/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/uid/TP40011195-CH4-SW6
 [network-access]: https://developer.apple.com/library/ios/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/uid/TP40011195-CH4-SW9

docs/tutorial/macos-dock.md

@@ -1,6 +1,4 @@
-# macOS Dock
-
-## Overview
+# Configuring the macOS Dock
 
 Electron has APIs to configure the app's icon in the macOS Dock. A macOS-only
 API exists to create a custom dock menu, but Electron also uses the app dock
@@ -24,8 +22,17 @@ Starting with a working application from the
  [Quick Start Guide](quick-start.md), update the `main.js` file with the
  following lines:
 
-```javascript
-const { app, Menu } = require('electron')
+```javascript fiddle='docs/fiddles/features/macos-dock-menu'
+const { app, BrowserWindow, Menu } = require('electron')
+
+function createWindow () {
+  const win = new BrowserWindow({
+    width: 800,
+    height: 600,
+  })
+
+  win.loadFile('index.html')
+}
 
 const dockMenu = Menu.buildFromTemplate([
   {
@@ -42,8 +49,23 @@ const dockMenu = Menu.buildFromTemplate([
 ])
 
 app.whenReady().then(() => {
-  app.dock.setMenu(dockMenu)
+  if (process.platform === 'darwin') {
+    app.dock.setMenu(dockMenu)
+  }
+}).then(createWindow)
+
+app.on('window-all-closed', () => {
+  if (process.platform !== 'darwin') {
+    app.quit()
+  }
 })
+
+app.on('activate', () => {
+  if (BrowserWindow.getAllWindows().length === 0) {
+    createWindow()
+  }
+})
+
 ```
 
 After launching the Electron application, right click the application icon.

docs/tutorial/message-ports.md

@@ -0,0 +1,325 @@
+# MessagePorts in Electron
+
+[`MessagePort`][]s are a web feature that allow passing messages between
+different contexts. It's like `window.postMessage`, but on different channels.
+The goal of this document is to describe how Electron extends the Channel
+Messaging model, and to give some examples of how you might use MessagePorts in
+your app.
+
+Here is a very brief example of what a MessagePort is and how it works:
+
+```js
+// renderer.js ///////////////////////////////////////////////////////////////
+// MessagePorts are created in pairs. A connected pair of message ports is
+// called a channel.
+const channel = new MessageChannel()
+
+// The only difference between port1 and port2 is in how you use them. Messages
+// sent to port1 will be received by port2 and vice-versa.
+const port1 = channel.port1
+const port2 = channel.port2
+
+// It's OK to send a message on the channel before the other end has registered
+// a listener. Messages will be queued until a listener is registered.
+port2.postMessage({ answer: 42 })
+
+// Here we send the other end of the channel, port1, to the main process. It's
+// also possible to send MessagePorts to other frames, or to Web Workers, etc.
+ipcRenderer.postMessage('port', null, [port1])
+```
+
+```js
+// main.js ///////////////////////////////////////////////////////////////////
+// In the main process, we receive the port.
+ipcMain.on('port', (event) => {
+  // When we receive a MessagePort in the main process, it becomes a
+  // MessagePortMain.
+  const port = event.ports[0]
+
+  // MessagePortMain uses the Node.js-style events API, rather than the
+  // web-style events API. So .on('message', ...) instead of .onmessage = ...
+  port.on('message', (event) => {
+    // data is { answer: 42 }
+    const data = event.data
+  })
+
+  // MessagePortMain queues messages until the .start() method has been called.
+  port.start()
+})
+```
+
+The [Channel Messaging API][] documentation is a great way to learn more about
+how MessagePorts work.
+
+## MessagePorts in the main process
+
+In the renderer, the `MessagePort` class behaves exactly as it does on the web.
+The main process is not a web page, though—it has no Blink integration—and so
+it does not have the `MessagePort` or `MessageChannel` classes. In order to
+handle and interact with MessagePorts in the main process, Electron adds two
+new classes: [`MessagePortMain`][] and [`MessageChannelMain`][]. These behave
+similarly to the analogous classes in the renderer.
+
+`MessagePort` objects can be created in either the renderer or the main
+process, and passed back and forth using the [`ipcRenderer.postMessage`][] and
+[`WebContents.postMessage`][] methods. Note that the usual IPC methods like
+`send` and `invoke` cannot be used to transfer `MessagePort`s, only the
+`postMessage` methods can transfer `MessagePort`s.
+
+By passing `MessagePort`s via the main process, you can connect two pages that
+might not otherwise be able to communicate (e.g. due to same-origin
+restrictions).
+
+## Extension: `close` event
+
+Electron adds one feature to `MessagePort` that isn't present on the web, in
+order to make MessagePorts more useful. That is the `close` event, which is
+emitted when the other end of the channel is closed. Ports can also be
+implicitly closed by being garbage-collected.
+
+In the renderer, you can listen for the `close` event either by assigning to
+`port.onclose` or by calling `port.addEventListener('close', ...)`. In the main
+process, you can listen for the `close` event by calling `port.on('close',
+...)`.
+
+## Example use cases
+
+### Worker process
+
+In this example, your app has a worker process implemented as a hidden window.
+You want the app page to be able to communicate directly with the worker
+process, without the performance overhead of relaying via the main process.
+
+```js
+// main.js ///////////////////////////////////////////////////////////////////
+const { BrowserWindow, app, ipcMain, MessageChannelMain } = require('electron')
+
+app.whenReady().then(async () => {
+  // The worker process is a hidden BrowserWindow, so that it will have access
+  // to a full Blink context (including e.g. <canvas>, audio, fetch(), etc.)
+  const worker = new BrowserWindow({
+    show: false,
+    webPreferences: { nodeIntegration: true }
+  })
+  await worker.loadFile('worker.html')
+
+  // The main window will send work to the worker process and receive results
+  // over a MessagePort.
+  const mainWindow = new BrowserWindow({
+    webPreferences: { nodeIntegration: true }
+  })
+  mainWindow.loadFile('app.html')
+
+  // We can't use ipcMain.handle() here, because the reply needs to transfer a
+  // MessagePort.
+  ipcMain.on('request-worker-channel', (event) => {
+    // For security reasons, let's make sure only the frames we expect can
+    // access the worker.
+    if (event.senderFrame === mainWindow.webContents.mainFrame) {
+      // Create a new channel ...
+      const { port1, port2 } = new MessageChannelMain()
+      // ... send one end to the worker ...
+      worker.webContents.postMessage('new-client', null, [port1])
+      // ... and the other end to the main window.
+      event.senderFrame.postMessage('provide-worker-channel', null, [port2])
+      // Now the main window and the worker can communicate with each other
+      // without going through the main process!
+    }
+  })
+})
+```
+
+```html
+<!-- worker.html ------------------------------------------------------------>
+<script>
+const { ipcRenderer } = require('electron')
+
+function doWork(input) {
+  // Something cpu-intensive.
+  return input * 2
+}
+
+// We might get multiple clients, for instance if there are multiple windows,
+// or if the main window reloads.
+ipcRenderer.on('new-client', (event) => {
+  const [ port ] = event.ports
+  port.onmessage = (event) => {
+    // The event data can be any serializable object (and the event could even
+    // carry other MessagePorts with it!)
+    const result = doWork(event.data)
+    port.postMessage(result)
+  }
+})
+</script>
+```
+
+```html
+<!-- app.html --------------------------------------------------------------->
+<script>
+const { ipcRenderer } = require('electron')
+
+// We request that the main process sends us a channel we can use to
+// communicate with the worker.
+ipcRenderer.send('request-worker-channel')
+
+ipcRenderer.once('provide-worker-channel', (event) => {
+  // Once we receive the reply, we can take the port...
+  const [ port ] = event.ports
+  // ... register a handler to receive results ...
+  port.onmessage = (event) => {
+    console.log('received result:', event.data)
+  }
+  // ... and start sending it work!
+  port.postMessage(21)
+})
+</script>
+```
+
+### Reply streams
+
+Electron's built-in IPC methods only support two modes: fire-and-forget
+(e.g. `send`), or request-response (e.g. `invoke`). Using MessageChannels, you
+can implement a "response stream", where a single request responds with a
+stream of data.
+
+```js
+// renderer.js ///////////////////////////////////////////////////////////////
+
+function makeStreamingRequest (element, callback) {
+  // MessageChannels are lightweight--it's cheap to create a new one for each
+  // request.
+  const { port1, port2 } = new MessageChannel()
+
+  // We send one end of the port to the main process ...
+  ipcRenderer.postMessage(
+    'give-me-a-stream',
+    { element, count: 10 },
+    [port2]
+  )
+
+  // ... and we hang on to the other end. The main process will send messages
+  // to its end of the port, and close it when it's finished.
+  port1.onmessage = (event) => {
+    callback(event.data)
+  }
+  port1.onclose = () => {
+    console.log('stream ended')
+  }
+}
+
+makeStreamingRequest(42, (data) => {
+  console.log('got response data:', event.data)
+})
+// We will see "got response data: 42" 10 times.
+```
+
+```js
+// main.js ///////////////////////////////////////////////////////////////////
+
+ipcMain.on('give-me-a-stream', (event, msg) => {
+  // The renderer has sent us a MessagePort that it wants us to send our
+  // response over.
+  const [replyPort] = event.ports
+
+  // Here we send the messages synchronously, but we could just as easily store
+  // the port somewhere and send messages asynchronously.
+  for (let i = 0; i < msg.count; i++) {
+    replyPort.postMessage(msg.element)
+  }
+
+  // We close the port when we're done to indicate to the other end that we
+  // won't be sending any more messages. This isn't strictly necessary--if we
+  // didn't explicitly close the port, it would eventually be garbage
+  // collected, which would also trigger the 'close' event in the renderer.
+  replyPort.close()
+})
+```
+
+### Communicating directly between the main process and the main world of a context-isolated page
+
+When [context isolation][] is enabled, IPC messages from the main process to
+the renderer are delivered to the isolated world, rather than to the main
+world. Sometimes you want to deliver messages to the main world directly,
+without having to step through the isolated world.
+
+```js
+// main.js ///////////////////////////////////////////////////////////////////
+const { BrowserWindow, app, MessageChannelMain } = require('electron')
+const path = require('path')
+
+app.whenReady().then(async () => {
+  // Create a BrowserWindow with contextIsolation enabled.
+  const bw = new BrowserWindow({
+    webPreferences: {
+      contextIsolation: true,
+      preload: path.join(__dirname, 'preload.js')
+    }
+  })
+  bw.loadURL('index.html')
+
+  // We'll be sending one end of this channel to the main world of the
+  // context-isolated page.
+  const { port1, port2 } = new MessageChannelMain()
+
+  // It's OK to send a message on the channel before the other end has
+  // registered a listener. Messages will be queued until a listener is
+  // registered.
+  port2.postMessage({ test: 21 })
+
+  // We can also receive messages from the main world of the renderer.
+  port2.on('message', (event) => {
+    console.log('from renderer main world:', event.data)
+  })
+  port2.start()
+
+  // The preload script will receive this IPC message and transfer the port
+  // over to the main world.
+  bw.webContents.postMessage('main-world-port', null, [port1])
+})
+```
+
+```js
+// preload.js ////////////////////////////////////////////////////////////////
+const { ipcRenderer } = require('electron')
+
+// We need to wait until the main world is ready to receive the message before
+// sending the port. We create this promise in the preload so it's guaranteed
+// to register the onload listener before the load event is fired.
+const windowLoaded = new Promise(resolve => {
+  window.onload = resolve
+})
+
+ipcRenderer.on('main-world-port', async (event) => {
+  await windowLoaded
+  // We use regular window.postMessage to transfer the port from the isolated
+  // world to the main world.
+  window.postMessage('main-world-port', '*', event.ports)
+})
+```
+
+```html
+<!-- index.html ------------------------------------------------------------->
+<script>
+window.onmessage = (event) => {
+  // event.source === window means the message is coming from the preload
+  // script, as opposed to from an <iframe> or other source.
+  if (event.source === window && event.data === 'main-world-port') {
+    const [ port ] = event.ports
+    // Once we have the port, we can communicate directly with the main
+    // process.
+    port.onmessage = (event) => {
+      console.log('from main process:', event.data)
+      port.postMessage(event.data * 2)
+    }
+  }
+}
+</script>
+```
+
+[context isolation]: context-isolation.md
+[`ipcRenderer.postMessage`]: ../api/ipc-renderer.md#ipcrendererpostmessagechannel-message-transfer
+[`WebContents.postMessage`]: ../api/web-contents.md#contentspostmessagechannel-message-transfer
+[`MessagePortMain`]: ../api/message-port-main.md
+[`MessageChannelMain`]: ../api/message-channel-main.md
+[`MessagePort`]: https://developer.mozilla.org/en-US/docs/Web/API/MessagePort
+[Channel Messaging API]: https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API

docs/tutorial/native-file-drag-drop.md

@@ -14,33 +14,49 @@ API in response to the `ondragstart` event.
 
 ## Example
 
-Starting with a working application from the
-[Quick Start Guide](quick-start.md), add the following lines to the
-`index.html` file:
+An example demonstrating how you can create a file on the fly to be dragged out of the window.
+
+### Preload.js
+
+In `preload.js` use the [`contextBridge`] to inject a method `window.electron.startDrag(...)` that will send an IPC message to the main process.
+
+```js
+const { contextBridge, ipcRenderer } = require('electron')
+const path = require('path')
+
+contextBridge.exposeInMainWorld('electron', {
+  startDrag: (fileName) => {
+    ipcRenderer.send('ondragstart', path.join(process.cwd(), fileName))
+  }
+})
+```
+
+### Index.html
+
+Add a draggable element to `index.html`, and reference your renderer script:
 
 ```html
-<a href="#" id="drag">Drag me</a>
+<div style="border:2px solid black;border-radius:3px;padding:5px;display:inline-block" draggable="true" id="drag">Drag me</div>
 <script src="renderer.js"></script>
 ```
 
-and add the following lines to the `renderer.js` file:
+### Renderer.js
 
-```js
-const { ipcRenderer } = require('electron')
+In `renderer.js` set up the renderer process to handle drag events by calling the method you added via the [`contextBridge`] above.
 
+```javascript
 document.getElementById('drag').ondragstart = (event) => {
   event.preventDefault()
-  ipcRenderer.send('ondragstart', '/absolute/path/to/the/item')
+  window.electron.startDrag('drag-and-drop.md')
 }
 ```
 
-The code above instructs the Renderer process to handle the `ondragstart` event
-and forward the information to the Main process.
+### Main.js
 
-In the Main process(`main.js` file), expand the received event with a path to the file that is
+In the Main process (`main.js` file), expand the received event with a path to the file that is
 being dragged and an icon:
 
-```javascript
+```javascript fiddle='docs/fiddles/features/drag-and-drop'
 const { ipcMain } = require('electron')
 
 ipcMain.on('ondragstart', (event, filePath) => {
@@ -52,7 +68,9 @@ ipcMain.on('ondragstart', (event, filePath) => {
 ```
 
 After launching the Electron application, try dragging and dropping
-the item from the BroswerWindow onto your desktop. In this guide,
+the item from the BrowserWindow onto your desktop. In this guide,
 the item is a Markdown file located in the root of the project:
 
 ![Drag and drop](../images/drag-and-drop.gif)
+
+[`contextBridge`]: ../api/context-bridge.md

docs/tutorial/notifications.md

@@ -28,7 +28,7 @@ Assuming you have a working Electron application from the
 
 and add the `renderer.js` file:
 
-```js
+```javascript fiddle='docs/fiddles/features/notifications/renderer'
 const myNotification = new Notification('Title', {
   body: 'Notification from the Renderer process'
 })
@@ -52,7 +52,7 @@ message that was generated after triggering the `onclick` event:
 Starting with a working application from the
 [Quick Start Guide](quick-start.md), update the `main.js` file with the following lines:
 
-```js
+```javascript fiddle='docs/fiddles/features/notifications/main'
 const { Notification } = require('electron')
 
 function showNotification () {

docs/tutorial/offscreen-rendering.md

@@ -1,59 +1,67 @@
 # Offscreen Rendering
 
-Offscreen rendering lets you obtain the content of a browser window in a bitmap,
-so it can be rendered anywhere, for example on a texture in a 3D scene. The
-offscreen rendering in Electron uses a similar approach than the [Chromium
-Embedded Framework](https://bitbucket.org/chromiumembedded/cef) project.
+## Overview
 
-Two modes of rendering can be used and only the dirty area is passed in the
-`'paint'` event to be more efficient. The rendering can be stopped, continued
-and the frame rate can be set. The specified frame rate is a top limit value,
-when there is nothing happening on a webpage, no frames are generated. The
-maximum frame rate is 60, because above that there is no benefit, only
-performance loss.
+Offscreen rendering lets you obtain the content of a `BrowserWindow` in a
+bitmap, so it can be rendered anywhere, for example, on texture in a 3D scene.
+The offscreen rendering in Electron uses a similar approach to that of the
+[Chromium Embedded Framework](https://bitbucket.org/chromiumembedded/cef)
+project.
 
-**Note:** An offscreen window is always created as a [Frameless Window](../api/frameless-window.md).
+*Notes*:
 
-## Rendering Modes
+* There are two rendering modes that can be used (see the section below) and only
+the dirty area is passed to the `paint` event to be more efficient.
+* You can stop/continue the rendering as well as set the frame rate.
+* The maximum frame rate is 240 because greater values bring only performance
+losses with no benefits.
+* When nothing is happening on a webpage, no frames are generated.
+* An offscreen window is always created as a
+[Frameless Window](../api/frameless-window.md).
 
-### GPU accelerated
+### Rendering Modes
+
+#### GPU accelerated
 
 GPU accelerated rendering means that the GPU is used for composition. Because of
-that the frame has to be copied from the GPU which requires more performance,
-thus this mode is quite a bit slower than the other one. The benefit of this
+that, the frame has to be copied from the GPU which requires more resources,
+thus this mode is slower than the Software output device. The benefit of this
 mode is that WebGL and 3D CSS animations are supported.
 
-### Software output device
+#### Software output device
 
 This mode uses a software output device for rendering in the CPU, so the frame
-generation is much faster, thus this mode is preferred over the GPU accelerated
-one.
+generation is much faster. As a result, this mode is preferred over the GPU
+accelerated one.
 
-To enable this mode GPU acceleration has to be disabled by calling the
+To enable this mode, GPU acceleration has to be disabled by calling the
 [`app.disableHardwareAcceleration()`][disablehardwareacceleration] API.
 
-## Usage
+## Example
 
-``` javascript
+Starting with a working application from the
+[Quick Start Guide](quick-start.md), add the following lines to the
+`main.js` file:
+
+```javascript fiddle='docs/fiddles/features/offscreen-rendering'
 const { app, BrowserWindow } = require('electron')
+const fs = require('fs')
 
 app.disableHardwareAcceleration()
 
 let win
 
 app.whenReady().then(() => {
-  win = new BrowserWindow({
-    webPreferences: {
-      offscreen: true
-    }
-  })
+  win = new BrowserWindow({ webPreferences: { offscreen: true } })
 
-  win.loadURL('http://github.com')
+  win.loadURL('https://github.com')
   win.webContents.on('paint', (event, dirty, image) => {
-    // updateBitmap(dirty, image.getBitmap())
+    fs.writeFileSync('ex.png', image.toPNG())
   })
-  win.webContents.setFrameRate(30)
+  win.webContents.setFrameRate(60)
 })
 ```
 
+After launching the Electron application, navigate to your application's
+working folder.
 [disablehardwareacceleration]: ../api/app.md#appdisablehardwareacceleration

docs/tutorial/online-offline-events.md

@@ -34,11 +34,11 @@ let onlineStatusWindow
 
 app.whenReady().then(() => {
   onlineStatusWindow = new BrowserWindow({ width: 0, height: 0, show: false })
-  onlineStatusWindow.loadURL(`file://${__dirname}/online-status.html`)
+  onlineStatusWindow.loadURL(`file://${__dirname}/index.html`)
 })
 ```
 
-create the `online-status.html` file and add the following line before the
+in the `index.html` file, add the following line before the
 closing `</body>` tag:
 
 ```html
@@ -47,7 +47,7 @@ closing `</body>` tag:
 
 and add the `renderer.js` file:
 
-```javascript
+```javascript fiddle='docs/fiddles/features/online-detection/renderer'
 const alertOnlineStatus = () => { window.alert(navigator.onLine ? 'online' : 'offline') }
 
 window.addEventListener('online', alertOnlineStatus)
@@ -78,7 +78,7 @@ let onlineStatusWindow
 
 app.whenReady().then(() => {
   onlineStatusWindow = new BrowserWindow({ width: 0, height: 0, show: false, webPreferences: { nodeIntegration: true } })
-  onlineStatusWindow.loadURL(`file://${__dirname}/online-status.html`)
+  onlineStatusWindow.loadURL(`file://${__dirname}/index.html`)
 })
 
 ipcMain.on('online-status-changed', (event, status) => {
@@ -86,7 +86,7 @@ ipcMain.on('online-status-changed', (event, status) => {
 })
 ```
 
-create the `online-status.html` file and add the following line before the
+in the `index.html` file, add the following line before the
 closing `</body>` tag:
 
 ```html
@@ -95,7 +95,7 @@ closing `</body>` tag:
 
 and add the `renderer.js` file:
 
-```javascript
+```javascript fiddle='docs/fiddles/features/online-detection/main'
 const { ipcRenderer } = require('electron')
 const updateOnlineStatus = () => { ipcRenderer.send('online-status-changed', navigator.onLine ? 'online' : 'offline') }
 

docs/tutorial/progress-bar.md

@@ -45,7 +45,7 @@ Starting with a working application from the
 [Quick Start Guide](quick-start.md), add the following lines to the
 `main.js` file:
 
-```javascript
+```javascript fiddle='docs/fiddles/features/progress-bar'
 const { BrowserWindow } = require('electron')
 const win = new BrowserWindow()
 

docs/tutorial/quick-start.md

@@ -28,10 +28,11 @@ If both commands succeeded, you are ready to install Electron.
 
 From a development perspective, an Electron application is essentially a Node.js application. This means that the starting point of your Electron application will be a `package.json` file like in any other Node.js application. A minimal Electron application has the following structure:
 
-```plain
+```plaintext
 my-electron-app/
 ├── package.json
 ├── main.js
+├── preload.js
 └── index.html
 ```
 
@@ -53,52 +54,55 @@ The main script specifies the entry point of your Electron application (in our c
 
 The main script may look as follows:
 
-```js
+```javascript fiddle='docs/fiddles/quick-start'
 const { app, BrowserWindow } = require('electron')
+const path = require('path')
 
 function createWindow () {
   const win = new BrowserWindow({
     width: 800,
     height: 600,
     webPreferences: {
-      nodeIntegration: true
+      preload: path.join(__dirname, 'preload.js')
     }
   })
 
   win.loadFile('index.html')
-  win.webContents.openDevTools()
 }
 
-app.whenReady().then(createWindow)
+app.whenReady().then(() => {
+  createWindow()
+
+  app.on('activate', () => {
+    if (BrowserWindow.getAllWindows().length === 0) {
+      createWindow()
+    }
+  })
+})
 
 app.on('window-all-closed', () => {
   if (process.platform !== 'darwin') {
     app.quit()
   }
 })
-
-app.on('activate', () => {
-  if (BrowserWindow.getAllWindows().length === 0) {
-    createWindow()
-  }
-})
 ```
 
 ##### What is going on above?
 
 1. Line 1: First, you import the `app` and `BrowserWindow` modules of the `electron` package to be able to manage your application's lifecycle events, as well as create and control browser windows.
-2. Line 3: After that, you define a function that creates a [new browser window](../api/browser-window.md#new-browserwindowoptions) with node integration enabled, loads `index.html` file into this window (line 12, we will discuss the file later) and opens Developer Tools (line 13).
-3. Line 16: You create a new browser window by invoking the `createWindow` function once the Electron application [is initialized](../api/app.md#appwhenready).
-4. Line 18: You add a new listener that tries to quit the application when it no longer has any open windows. This listener is a no-op on macOS due to the operating system's [window management behavior](https://support.apple.com/en-ca/guide/mac-help/mchlp2469/mac).
-5. Line 24: You add a new listener that creates a new browser window only if when the application has no visible windows after being activated. For example, after launching the application for the first time, or re-launching the already running application.
+2. Line 2: Second, you import the `path` package which provides utility functions for file paths.
+3. Line 4: After that, you define a function that creates a [new browser window](../api/browser-window.md#new-browserwindowoptions) with a preload script, loads `index.html` file into this window (line 13, we will discuss the file later).
+4. Line 16: You create a new browser window by invoking the `createWindow` function once the Electron application [is initialized](../api/app.md#appwhenready).
+5. Line 18: You add a new listener that creates a new browser window only if when the application has no visible windows after being activated. For example, after launching the application for the first time, or re-launching the already running application.
+6. Line 25: You add a new listener that tries to quit the application when it no longer has any open windows. This listener is a no-op on macOS due to the operating system's [window management behavior](https://support.apple.com/en-ca/guide/mac-help/mchlp2469/mac).
 
 #### Create a web page
 
-This is the web page you want to display once the application is initialized. This web page represents the Renderer process. You can create multiple browser windows, where each window uses its own independent Renderer. Each window can optionally be granted with full access to Node.js API through the `nodeIntegration` preference.
+This is the web page you want to display once the application is initialized. This web page represents the Renderer process. You can create multiple browser windows, where each window uses its own independent Renderer. You can optionally grant access to additional Node.js APIs by exposing them from your preload script.
 
 The `index.html` page looks as follows:
 
-```html
+```html fiddle='docs/fiddles/quick-start'
 <!DOCTYPE html>
 <html>
 <head>
@@ -108,13 +112,39 @@ The `index.html` page looks as follows:
 </head>
 <body style="background: white;">
     <h1>Hello World!</h1>
-    We are using node <script>document.write(process.versions.node)</script>,
-    Chrome <script>document.write(process.versions.chrome)</script>,
-    and Electron <script>document.write(process.versions.electron)</script>.
+    <p>
+        We are using Node.js <span id="node-version"></span>,
+        Chromium <span id="chrome-version"></span>,
+        and Electron <span id="electron-version"></span>.
+    </p>
 </body>
 </html>
 ```
 
+#### Define a preload script
+
+Your preload script (in our case, the `preload.js` file) acts as a bridge between Node.js and your web page. It allows you to expose specific APIs and behaviors to your web page rather than insecurely exposing the entire Node.js API. In this example we will use the preload script to read version information from the `process` object and update the web page with that info.
+
+```javascript fiddle='docs/fiddles/quick-start'
+window.addEventListener('DOMContentLoaded', () => {
+  const replaceText = (selector, text) => {
+    const element = document.getElementById(selector)
+    if (element) element.innerText = text
+  }
+
+  for (const type of ['chrome', 'node', 'electron']) {
+    replaceText(`${type}-version`, process.versions[type])
+  }
+})
+```
+
+##### What's going on above?
+
+1. On line 1: First you define an event listener that tells you when the web page has loaded
+2. On line 2: Second you define a utility function used to set the text of the placeholders in the `index.html`
+3. On line 7: Next you loop through the list of components whose version you want to display
+4. On line 8: Finally, you call `replaceText` to look up the version placeholders in `index.html` and set their text value to the values from `process.versions`
+
 #### Modify your package.json file
 
 Your Electron application uses the `package.json` file as the main entry point (as any other Node.js application). The main script of your application is `main.js`, so modify the `package.json` file accordingly:
@@ -123,18 +153,24 @@ Your Electron application uses the `package.json` file as the main entry point (
 {
     "name": "my-electron-app",
     "version": "0.1.0",
+    "author": "your name",
+    "description": "My Electron app",
     "main": "main.js"
 }
 ```
 
 > NOTE: If the `main` field is omitted, Electron will attempt to load an `index.js` file from the directory containing `package.json`.
 
+> NOTE: The `author` and `description` fields are required for packaging, otherwise error will occur when running `npm run make`.
+
 By default, the `npm start` command will run the main script with Node.js. To run the script with Electron, you need to change it as such:
 
 ```json
 {
     "name": "my-electron-app",
     "version": "0.1.0",
+    "author": "your name",
+    "description": "My Electron app",
     "main": "main.js",
     "scripts": {
         "start": "electron ."
@@ -160,7 +196,8 @@ The simplest and the fastest way to distribute your newly created app is using
 1. Import Electron Forge to your app folder:
 
     ```sh
-    npx @electron-forge/cli import
+    npm install --save-dev @electron-forge/cli
+    npx electron-forge import
 
     ✔ Checking your system
     ✔ Initializing Git Repository
@@ -275,7 +312,7 @@ ipcRenderer.invoke('perform-action', ...args)
 
 ##### Node.js API
 
-> NOTE: To access the Node.js API from the Renderer process, you need to set the `nodeIntegration` preference to `true`.
+> NOTE: To access the Node.js API from the Renderer process, you need to set the `nodeIntegration` preference to `true` and the `contextIsolation` preference to `false`.  Please note that access to the Node.js API in any renderer that loads remote content is not recommended for [security reasons](../tutorial/security.md#2-do-not-enable-nodejs-integration-for-remote-content).
 
 Electron exposes full access to Node.js API and its modules both in the Main and the Renderer processes. For example, you can read all the files from the root directory:
 

docs/tutorial/recent-documents.md

@@ -24,7 +24,7 @@ Starting with a working application from the
 [Quick Start Guide](quick-start.md), add the following lines to the
 `main.js` file:
 
-```javascript
+```javascript fiddle='docs/fiddles/features/recent-documents'
 const { app } = require('electron')
 
 app.addRecentDocument('/Users/USERNAME/Desktop/work.type')
@@ -83,6 +83,22 @@ following code snippet to your menu template:
 }
 ```
 
+Make sure the application menu is added after the [`'ready'`](../api/app.md#event-ready)
+event and not before, or the menu item will be disabled:
+
+```javascript
+const { app, Menu } = require('electron')
+
+const template = [
+  // Menu template here
+]
+const menu = Menu.buildFromTemplate(template)
+
+app.whenReady().then(() => {
+  Menu.setApplicationMenu(menu)
+})
+```
+
 ![macOS Recent Documents menu item][menu-item-image]
 
 When a file is requested from the recent documents menu, the `open-file` event

docs/tutorial/repl.md

@@ -1,27 +1,23 @@
 # REPL
 
-Read-Eval-Print-Loop (REPL) is a simple, interactive computer programming
-environment that takes single user inputs (i.e. single expressions), evaluates
-them, and returns the result to the user.
+[Read-Eval-Print-Loop](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop) (REPL)
+is a simple, interactive computer programming environment that takes single user
+inputs (i.e. single expressions), evaluates them, and returns the result to the user.
 
-The `repl` module provides a REPL implementation that can be accessed using:
+## Main process
 
-* Assuming you have `electron` or `electron-prebuilt` installed as a local
-  project dependency:
+Electron exposes the [Node.js `repl` module](https://nodejs.org/dist/latest/docs/api/repl.html)
+through the `--interactive` CLI flag. Assuming you have `electron` installed as a local project
+dependency, you should be able to access the REPL with the following command:
 
   ```sh
   ./node_modules/.bin/electron --interactive
   ```
 
-* Assuming you have `electron` or `electron-prebuilt` installed globally:
+**Note:** `electron --interactive` is not available on Windows
+(see [electron/electron#5776](https://github.com/electron/electron/pull/5776) for more details).
 
-  ```sh
-  electron --interactive
-  ```
+## Renderer process
 
-This only creates a REPL for the main process. You can use the Console
-tab of the Dev Tools to get a REPL for the renderer processes.
-
-**Note:** `electron --interactive` is not available on Windows.
-
-More information can be found in the [Node.js REPL docs](https://nodejs.org/dist/latest/docs/api/repl.html).
+You can use the DevTools Console tab to get a REPL for any renderer process.
+To learn more, read [the Chrome documentation](https://developer.chrome.com/docs/devtools/console/).

docs/tutorial/represented-file.md

@@ -24,7 +24,7 @@ Starting with a working application from the
 [Quick Start Guide](quick-start.md), add the following lines to the
 `main.js` file:
 
-```javascript
+```javascript fiddle='docs/fiddles/features/represented-file'
 const { app, BrowserWindow } = require('electron')
 
 app.whenReady().then(() => {

docs/tutorial/sandbox.md

@@ -0,0 +1,169 @@
+# Process Sandboxing
+
+One key security feature in Chromium is that processes can be executed within a sandbox.
+The sandbox limits the harm that malicious code can cause by limiting access to most
+system resources — sandboxed processes can only freely use CPU cycles and memory.
+In order to perform operations requiring additional privilege, sandboxed processes
+use dedicated communication channels to delegate tasks to more privileged processes.
+
+In Chromium, sandboxing is applied to most processes other than the main process.
+This includes renderer processes, as well as utility processes such as the audio service,
+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.
+
+## Sandbox behaviour in Electron
+
+Sandboxed processes in Electron behave _mostly_ in the same way as Chromium's do, but
+Electron has a few additional concepts to consider because it interfaces with Node.js.
+
+### Renderer processes
+
+When renderer processes in Electron are sandboxed, they behave in the same way as 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).
+
+### Preload scripts
+
+In order to allow renderer processes to communicate with the main process, preload
+scripts attached to sandboxed renderers will still have a polyfilled subset of Node.js
+APIs available. A `require` function similar to Node's `require` module is exposed,
+but can only import a subset of Electron and Node's built-in modules:
+
+* `electron` (only renderer process modules)
+* [`events`](https://nodejs.org/api/events.html)
+* [`timers`](https://nodejs.org/api/timers.html)
+* [`url`](https://nodejs.org/api/url.html)
+
+In addition, the preload script also polyfills certain Node.js primitives as globals:
+
+* [`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)
+
+Because the `require` function is a polyfill with limited functionality, you will not be
+able to use [CommonJS modules][commonjs] to separate your preload script into multiple
+files. If you need to split your preload code, use a bundler such as [webpack][webpack]
+or [Parcel][parcel].
+
+Note that because the environment presented to the `preload` script is substantially
+more privileged than that of a sandboxed renderer, it is still possible to leak
+privileged APIs to untrusted code running in the renderer process unless
+[`contextIsolation`][contextIsolation] is enabled.
+
+## Configuring the sandbox
+
+### Enabling the sandbox for a single process
+
+In Electron, renderer sandboxing can be enabled on a per-process basis with
+the `sandbox: true` preference in the [`BrowserWindow`][browser-window] constructor.
+
+```js
+// main.js
+app.whenReady().then(() => {
+  const win = new BrowserWindow({
+    webPreferences: {
+      sandbox: 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
+app.enableSandbox()
+app.whenReady().then(() => {
+  // no need to pass `sandbox: true` since `app.enableSandbox()` was called.
+  const win = new BrowserWindow()
+  win.loadURL('https://google.com')
+})
+```
+
+### Disabling Chromium's sandbox (testing only)
+
+You can also disable Chromium's sandbox entirely with the [`--no-sandbox`][no-sandbox]
+CLI flag, which will disable the sandbox for all processes (including utility processes).
+We highly recommend that you only use this flag for testing purposes, and **never**
+in production.
+
+Note that the `sandbox: true` option will still disable the renderer's Node.js
+environment.
+
+## A note on rendering untrusted content
+
+Rendering untrusted content in Electron is still somewhat uncharted territory,
+though some apps are finding success (e.g. [Beaker Browser][beaker]).
+Our goal is to get as close to Chrome as we can in terms of the security of
+sandboxed content, but ultimately we will always be behind due to a few fundamental
+issues:
+
+1. We do not have the dedicated resources or expertise that Chromium has to
+   apply to the security of its product. We do our best to make use of what we
+   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
+   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
+   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
+   to upgrade the version of Electron underlying their app in order for
+   security updates to reach users.
+
+While we make our best effort to backport Chromium security fixes to older
+versions of Electron, we do not make a guarantee that every fix will be
+backported. Your best chance at staying secure is to be on the latest stable
+version of Electron.
+
+[sandbox]: https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md
+[issue-28466]: https://github.com/electron/electron/issues/28466
+[browser-window]: ../api/browser-window.md
+[enable-sandbox]: ../api/app.md#appenablesandbox
+[no-sandbox]: ../api/command-line-switches.md#--no-sandbox
+[commonjs]: https://nodejs.org/api/modules.html#modules_modules_commonjs_modules
+[webpack]: https://webpack.js.org/
+[parcel]: https://parceljs.org/
+[context-isolation]: ./context-isolation.md
+[beaker]: https://github.com/beakerbrowser/beaker

docs/tutorial/security.md

@@ -44,7 +44,7 @@ Chromium shared library and Node.js. Vulnerabilities affecting these components
 may impact the security of your application. By updating Electron to the latest
 version, you ensure that critical vulnerabilities (such as *nodeIntegration bypasses*)
 are already patched and cannot be exploited in your application. For more information,
-see "[Use a current version of Electron](#17-use-a-current-version-of-electron)".
+see "[Use a current version of Electron](#15-use-a-current-version-of-electron)".
 
 * **Evaluate your dependencies.** While NPM provides half a million reusable packages,
 it is your responsibility to choose trusted 3rd-party libraries. If you use outdated
@@ -99,9 +99,7 @@ You should at least follow these steps to improve the security of your applicati
 12. [Disable or limit navigation](#12-disable-or-limit-navigation)
 13. [Disable or limit creation of new windows](#13-disable-or-limit-creation-of-new-windows)
 14. [Do not use `openExternal` with untrusted content](#14-do-not-use-openexternal-with-untrusted-content)
-15. [Disable the `remote` module](#15-disable-the-remote-module)
-16. [Filter the `remote` module](#16-filter-the-remote-module)
-17. [Use a current version of Electron](#17-use-a-current-version-of-electron)
+15. [Use a current version of Electron](#15-use-a-current-version-of-electron)
 
 To automate the detection of misconfigurations and insecure patterns, it is
 possible to use
@@ -665,134 +663,7 @@ const { shell } = require('electron')
 shell.openExternal('https://example.com/index.html')
 ```
 
-## 15) Disable the `remote` module
-
-The `remote` module provides a way for the renderer processes to
-access APIs normally only available in the main process. Using it, a
-renderer can invoke methods of a main process object without explicitly sending
-inter-process messages. If your desktop application does not run untrusted
-content, this can be a useful way to have your renderer processes access and
-work with modules that are only available to the main process, such as
-GUI-related modules (dialogs, menus, etc.).
-
-However, if your app can run untrusted content and even if you
-[sandbox][sandbox] your renderer processes accordingly, the `remote` module
-makes it easy for malicious code to escape the sandbox and have access to
-system resources via the higher privileges of the main process. Therefore,
-it should be disabled in such circumstances.
-
-### Why?
-
-`remote` uses an internal IPC channel to communicate with the main process.
-"Prototype pollution" attacks can grant malicious code access to the internal
-IPC channel, which can then be used to escape the sandbox by mimicking `remote`
-IPC messages and getting access to main process modules running with higher
-privileges.
-
-Additionally, it's possible for preload scripts to accidentally leak modules to a
-sandboxed renderer. Leaking `remote` arms malicious code with a multitude
-of main process modules with which to perform an attack.
-
-Disabling the `remote` module eliminates these attack vectors. Enabling
-context isolation also prevents the "prototype pollution" attacks from
-succeeding.
-
-### How?
-
-```js
-// Bad if the renderer can run untrusted content
-const mainWindow = new BrowserWindow({
-  webPreferences: {
-    enableRemoteModule: true
-  }
-})
-```
-
-```js
-// Good
-const mainWindow = new BrowserWindow({
-  webPreferences: {
-    enableRemoteModule: false
-  }
-})
-```
-
-```html
-<!-- Bad if the renderer can run untrusted content  -->
-<webview enableremotemodule="true" src="page.html"></webview>
-
-<!-- Good -->
-<webview enableremotemodule="false" src="page.html"></webview>
-```
-
-> **Note:** The default value of `enableRemoteModule` is `false` starting
-> from Electron 10. For prior versions, you need to explicitly disable
-> the `remote` module by the means above.
-
-## 16) Filter the `remote` module
-
-If you cannot disable the `remote` module, you should filter the globals,
-Node, and Electron modules (so-called built-ins) accessible via `remote`
-that your application does not require. This can be done by blocking
-certain modules entirely and by replacing others with proxies that
-expose only the functionality that your app needs.
-
-### Why?
-
-Due to the system access privileges of the main process, functionality
-provided by the main process modules may be dangerous in the hands of
-malicious code running in a compromised renderer process. By limiting
-the set of accessible modules to the minimum that your app needs and
-filtering out the others, you reduce the toolset that malicious code
-can use to attack the system.
-
-Note that the safest option is to
-[fully disable the remote module](#15-disable-the-remote-module). If
-you choose to filter access rather than completely disable the module,
-you must be very careful to ensure that no escalation of privilege is
-possible through the modules you allow past the filter.
-
-### How?
-
-```js
-const readOnlyFsProxy = require(/* ... */) // exposes only file read functionality
-
-const allowedModules = new Set(['crypto'])
-const proxiedModules = new Map(['fs', readOnlyFsProxy])
-const allowedElectronModules = new Set(['shell'])
-const allowedGlobals = new Set()
-
-app.on('remote-require', (event, webContents, moduleName) => {
-  if (proxiedModules.has(moduleName)) {
-    event.returnValue = proxiedModules.get(moduleName)
-  }
-  if (!allowedModules.has(moduleName)) {
-    event.preventDefault()
-  }
-})
-
-app.on('remote-get-builtin', (event, webContents, moduleName) => {
-  if (!allowedElectronModules.has(moduleName)) {
-    event.preventDefault()
-  }
-})
-
-app.on('remote-get-global', (event, webContents, globalName) => {
-  if (!allowedGlobals.has(globalName)) {
-    event.preventDefault()
-  }
-})
-
-app.on('remote-get-current-window', (event, webContents) => {
-  event.preventDefault()
-})
-
-app.on('remote-get-current-web-contents', (event, webContents) => {
-  event.preventDefault()
-})
-```
-
-## 17) Use a current version of Electron
+## 15) Use a current version of Electron
 
 You should strive for always using the latest available version of Electron.
 Whenever a new major version is released, you should attempt to update your
@@ -821,5 +692,5 @@ which potential security issues are not as widely known.
 [window-open-handler]: ../api/web-contents.md#contentssetwindowopenhandlerhandler
 [will-navigate]: ../api/web-contents.md#event-will-navigate
 [open-external]: ../api/shell.md#shellopenexternalurl-options
-[sandbox]: ../api/sandbox-option.md
+[sandbox]: ../tutorial/sandbox.md
 [responsible-disclosure]: https://en.wikipedia.org/wiki/Responsible_disclosure

docs/tutorial/snapcraft.md

@@ -83,7 +83,7 @@ snap(options)
 
 ### Step 1: Create Sample Snapcraft Project
 
-Create your project directory and add add the following to `snap/snapcraft.yaml`:
+Create your project directory and add the following to `snap/snapcraft.yaml`:
 
 ```yaml
 name: electron-packager-hello-world

docs/tutorial/spellchecker.md

@@ -71,4 +71,4 @@ Although the spellchecker itself does not send any typings, words or user input
 myWindow.session.setSpellCheckerDictionaryDownloadURL('https://example.com/dictionaries/')
 ```
 
-Check out the docs for [`session.setSpellCheckerDictionaryDownloadURL`](https://www.electronjs.org/docs/api/session#sessetspellcheckerdictionarydownloadurlurl) for more information on where to get the dictionary files from and how you need to host them.
+Check out the docs for [`session.setSpellCheckerDictionaryDownloadURL`](../api/session.md#sessetspellcheckerdictionarydownloadurlurl) for more information on where to get the dictionary files from and how you need to host them.

docs/tutorial/support.md

@@ -10,21 +10,21 @@ for answers to questions,
 or to join in discussion with other developers who use Electron,
 you can interact with the community in these locations:
 
-- [`Electron's Discord`](https://discord.com/invite/electron) has channels for:
-  - Getting help
-  - Ecosystem apps like [Electron Forge](https://github.com/electron-userland/electron-forge) and [Electron Fiddle](https://github.com/electron/fiddle)
-  - Sharing ideas with other Electron app developers
-  - And more!
-- [`electron`](https://discuss.atom.io/c/electron) category on the Atom forums
-- `#atom-shell` channel on Freenode
-- `#electron` channel on [Atom's Slack](https://discuss.atom.io/t/join-us-on-slack/16638?source_topic_id=25406)
-- [`electron-ru`](https://telegram.me/electron_ru) *(Russian)*
-- [`electron-br`](https://electron-br.slack.com) *(Brazilian Portuguese)*
-- [`electron-kr`](https://electron-kr.github.io/electron-kr) *(Korean)*
-- [`electron-jp`](https://electron-jp.slack.com) *(Japanese)*
-- [`electron-tr`](https://electron-tr.herokuapp.com) *(Turkish)*
-- [`electron-id`](https://electron-id.slack.com) *(Indonesia)*
-- [`electron-pl`](https://electronpl.github.io) *(Poland)*
+* [`Electron's Discord`](https://discord.com/invite/electron) has channels for:
+  * Getting help
+  * Ecosystem apps like [Electron Forge](https://github.com/electron-userland/electron-forge) and [Electron Fiddle](https://github.com/electron/fiddle)
+  * Sharing ideas with other Electron app developers
+  * And more!
+* [`electron`](https://discuss.atom.io/c/electron) category on the Atom forums
+* `#atom-shell` channel on Freenode
+* `#electron` channel on [Atom's Slack](https://discuss.atom.io/t/join-us-on-slack/16638?source_topic_id=25406)
+* [`electron-ru`](https://telegram.me/electron_ru) *(Russian)*
+* [`electron-br`](https://electron-br.slack.com) *(Brazilian Portuguese)*
+* [`electron-kr`](https://electron-kr.github.io/electron-kr) *(Korean)*
+* [`electron-jp`](https://electron-jp.slack.com) *(Japanese)*
+* [`electron-tr`](https://electron-tr.herokuapp.com) *(Turkish)*
+* [`electron-id`](https://electron-id.slack.com) *(Indonesia)*
+* [`electron-pl`](https://electronpl.github.io) *(Poland)*
 
 If you'd like to contribute to Electron,
 see the [contributing document](https://github.com/electron/electron/blob/master/CONTRIBUTING.md).
@@ -64,9 +64,9 @@ until the maintainers feel the maintenance burden is too high to continue doing
 
 ### Currently supported versions
 
-- 11.x.y
-- 10.x.y
-- 9.x.y
+* 12.x.y
+* 11.x.y
+* 10.x.y
 
 ### End-of-life
 
@@ -94,7 +94,9 @@ Following platforms are supported by Electron:
 ### macOS
 
 Only 64bit binaries are provided for macOS, and the minimum macOS version
-supported is macOS 10.10 (Yosemite).
+supported is macOS 10.11 (El Capitan).
+
+Native support for Apple Silicon (`arm64`) devices was added in Electron 11.0.0.
 
 ### Windows
 
@@ -102,7 +104,7 @@ Windows 7 and later are supported, older operating systems are not supported
 (and do not work).
 
 Both `ia32` (`x86`) and `x64` (`amd64`) binaries are provided for Windows.
-[Electron 6.0.8 and later add native support for Windows on Arm (`arm64`) devices](windows-arm.md).
+[Native support for Windows on Arm (`arm64`) devices was added in Electron 6.0.8.](windows-arm.md).
 Running apps packaged with previous versions is possible using the ia32 binary.
 
 ### Linux

docs/tutorial/using-native-node-modules.md

@@ -1,8 +1,9 @@
 # Using Native Node Modules
 
-Native Node modules are supported by Electron, but since Electron is very
-likely to use a different V8 version from the Node binary installed on your
-system, the modules you use will need to be recompiled for Electron. Otherwise,
+Native Node.js modules are supported by Electron, but since Electron has a different
+[application binary interface (ABI)][abi] from a given Node.js binary (due to
+differences such as using Chromium's BoringSSL instead of OpenSSL), the native
+modules you use will need to be recompiled for Electron. Otherwise,
 you will get the following class of error when you try to run your app:
 
 ```sh
@@ -23,9 +24,11 @@ You can install modules like other Node projects, and then rebuild the modules
 for Electron with the [`electron-rebuild`][electron-rebuild] package. This
 module can automatically determine the version of Electron and handle the
 manual steps of downloading headers and rebuilding native modules for your app.
+If you are using [Electron Forge][electron-forge], this tool is used automatically
+in both development mode and when making distributables.
 
-For example, to install `electron-rebuild` and then rebuild modules with it
-via the command line:
+For example, to install the standalone `electron-rebuild` tool and then rebuild
+modules with it via the command line:
 
 ```sh
 npm install --save-dev electron-rebuild
@@ -33,12 +36,12 @@ npm install --save-dev electron-rebuild
 # Every time you run "npm install", run this:
 ./node_modules/.bin/electron-rebuild
 
-# On Windows if you have trouble, try:
+# If you have trouble on Windows, try:
 .\node_modules\.bin\electron-rebuild.cmd
 ```
 
-For more information on usage and integration with other tools, consult the
-project's README.
+For more information on usage and integration with other tools such as [Electron
+Packager][electron-packager], consult the project's README.
 
 ### Using `npm`
 
@@ -129,13 +132,13 @@ should look like this:
 
 In particular, it's important that:
 
-- you link against `node.lib` from _Electron_ and not Node. If you link against
+* you link against `node.lib` from _Electron_ and not Node. If you link against
   the wrong `node.lib` you will get load-time errors when you require the
   module in Electron.
-- you include the flag `/DELAYLOAD:node.exe`. If the `node.exe` link is not
+* you include the flag `/DELAYLOAD:node.exe`. If the `node.exe` link is not
   delayed, then the delay-load hook won't get a chance to fire and the node
   symbols won't be correctly resolved.
-- `win_delay_load_hook.obj` is linked directly into the final DLL. If the hook
+* `win_delay_load_hook.obj` is linked directly into the final DLL. If the hook
   is set up in a dependent DLL, it won't fire at the right time.
 
 See [`node-gyp`](https://github.com/nodejs/node-gyp/blob/e2401e1395bef1d3c8acec268b42dc5fb71c4a38/src/win_delay_load_hook.cc)
@@ -147,23 +150,25 @@ for an example delay-load hook if you're implementing your own.
 native Node modules with prebuilt binaries for multiple versions of Node
 and Electron.
 
-If modules provide binaries for the usage in Electron, make sure to omit
-`--build-from-source` and the `npm_config_build_from_source` environment
-variable in order to take full advantage of the prebuilt binaries.
+If the `prebuild`-powered module provide binaries for the usage in Electron,
+make sure to omit `--build-from-source` and the `npm_config_build_from_source`
+environment variable in order to take full advantage of the prebuilt binaries.
 
 ## Modules that rely on `node-pre-gyp`
 
 The [`node-pre-gyp` tool][node-pre-gyp] provides a way to deploy native Node
 modules with prebuilt binaries, and many popular modules are using it.
 
-Usually those modules work fine under Electron, but sometimes when Electron uses
-a newer version of V8 than Node and/or there are ABI changes, bad things may
-happen. So in general, it is recommended to always build native modules from
-source code. `electron-rebuild` handles this for you automatically.
+Sometimes those modules work fine under Electron, but when there are no
+Electron-specific binaries available, you'll need to build from source.
+Because of this, it is recommended to use `electron-rebuild` for these modules.
 
-If you are following the `npm` way of installing modules, then this is done
-by default, if not, you have to pass `--build-from-source` to `npm`, or set the
-`npm_config_build_from_source` environment variable.
+If you are following the `npm` way of installing modules, you'll need to pass
+`--build-from-source` to `npm`, or set the `npm_config_build_from_source`
+environment variable.
 
+[abi]: https://en.wikipedia.org/wiki/Application_binary_interface
 [electron-rebuild]: https://github.com/electron/electron-rebuild
+[electron-forge]: https://electronforge.io/
+[electron-packager]: https://github.com/electron/electron-packager
 [node-pre-gyp]: https://github.com/mapbox/node-pre-gyp

docs/tutorial/using-selenium-and-webdriver.md

@@ -86,12 +86,12 @@ const driver = new webdriver.Builder()
   // The "9515" is the port opened by chrome driver.
   .usingServer('http://localhost:9515')
   .withCapabilities({
-    chromeOptions: {
+    'goog:chromeOptions': {
       // Here is the path to your Electron binary.
       binary: '/Path-to-Your-App.app/Contents/MacOS/Electron'
     }
   })
-  .forBrowser('electron')
+  .forBrowser('chrome') // note: use .forBrowser('electron') for selenium-webdriver <= 3.6.0
   .build()
 
 driver.get('http://www.google.com')

docs/tutorial/web-embeds.md

@@ -20,7 +20,7 @@ and only allow the capabilities you want to support.
 ### WebViews
 
 > Important Note:
-[we do not recommend you to use use WebViews](https://www.electronjs.org/docs/api/webview-tag#warning),
+[we do not recommend you to use WebViews](../api/webview-tag.md#warning),
 as this tag undergoes dramatic architectural changes that may affect stability
 of your application. Consider switching to alternatives, like `iframe` and
 Electron's `BrowserView`, or an architecture that avoids embedded content