docs: backport current tutorials to 12-x-y (#28396)

docs/README.md

@@ -91,11 +91,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)
 
 ---
@@ -150,7 +145,6 @@ These individual tutorials expand on topics discussed in the guide above.
 
 * [contextBridge](api/context-bridge.md)
 * [ipcRenderer](api/ipc-renderer.md)
-* [remote](api/remote.md)
 * [webFrame](api/web-frame.md)
 
 ### Modules for Both Processes:

docs/breaking-changes.md

@@ -6,14 +6,20 @@ 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
@@ -24,6 +30,28 @@ You will be affected by this change if you use either `webFrame.executeJavaScrip
 
 ## 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
@@ -36,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
@@ -60,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()`
@@ -79,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.
 
@@ -135,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.
@@ -174,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`.
@@ -221,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.
@@ -233,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.
@@ -285,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)`
@@ -293,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()`
@@ -373,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`.
 
@@ -387,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`:
 
@@ -470,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`
 
@@ -487,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`

docs/development/build-instructions-gn.md

@@ -86,8 +86,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 +139,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 +181,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

@@ -55,6 +55,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/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/fiddles/quick-start/index.html

@@ -8,8 +8,8 @@
 <body>
     <h1>Hello World!</h1>
     <p>
-        We are using node <span id="node-version"></span>,
-        Chrome <span id="chrome-version"></span>,
+        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>

docs/styleguide.md

@@ -49,6 +49,7 @@ For API references, there are exceptions to this rule.
 * 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
 

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.
+
+> *NOTE:* the location of Electron's prebuilt binaries is indicated
+with `electron/` in the examples below.
 
-On macOS:
+*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/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.
@@ -96,7 +96,7 @@ color scheme, and update the "Current Theme Source" label to `System`.
 
 To add listeners and handlers, add the following lines to the `renderer.js` file:
 
-```js
+```javascript
 const { ipcRenderer } = require('electron')
 
 document.getElementById('toggle-dark-mode').addEventListener('click', async () => {
@@ -130,7 +130,7 @@ 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`.
 
-```js
+```javascript
 const { app, BrowserWindow, ipcMain, nativeTheme } = require('electron')
 
 function createWindow () {
@@ -154,7 +154,7 @@ function createWindow () {
   })
 
   ipcMain.handle('dark-mode:system', () => {
-    nativeTheme.themeSouce = 'system'
+    nativeTheme.themeSource = 'system'
   })
 }
 
@@ -180,7 +180,7 @@ attribute. The value of `prefers-color-scheme` will follow your
 
 Create a `styles.css` file and add the following lines:
 
-```css
+```css fiddle='docs/fiddles/features/macos-dark-mode'
 @media (prefers-color-scheme: dark) {
   body { background:  #333; color: white; }
 }

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`.
+**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`.
 
 #### 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')

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/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/macos-dock.md

@@ -24,7 +24,7 @@ Starting with a working application from the
  [Quick Start Guide](quick-start.md), update the `main.js` file with the
  following lines:
 
-```javascript
+```javascript fiddle='docs/fiddles/features/macos-dock-menu'
 const { app, Menu } = require('electron')
 
 const dockMenu = Menu.buildFromTemplate([

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

@@ -25,7 +25,7 @@ Starting with a working application from the
 
 and add the following lines to the `renderer.js` file:
 
-```js
+```javascript
 const { ipcRenderer } = require('electron')
 
 document.getElementById('drag').ondragstart = (event) => {
@@ -40,7 +40,7 @@ and forward the information to the Main process.
 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 +52,7 @@ 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)

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 240, 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
+
+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/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,7 +28,7 @@ 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
@@ -54,7 +54,7 @@ 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')
 
@@ -68,7 +68,6 @@ function createWindow () {
   })
 
   win.loadFile('index.html')
-  win.webContents.openDevTools()
 }
 
 app.whenReady().then(() => {
@@ -103,7 +102,7 @@ This is the web page you want to display once the application is initialized. Th
 
 The `index.html` page looks as follows:
 
-```html
+```html fiddle='docs/fiddles/quick-start'
 <!DOCTYPE html>
 <html>
 <head>
@@ -113,9 +112,11 @@ The `index.html` page looks as follows:
 </head>
 <body style="background: white;">
     <h1>Hello World!</h1>
-    We are using node <span id="node-version"></span>,
-    Chrome <span id="chrome-version"></span>,
-    and Electron <span id="electron-version"></span>.
+    <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>
 ```
@@ -152,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 ."
@@ -189,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

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')

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/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

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
 
@@ -96,13 +96,15 @@ Following platforms are supported by Electron:
 Only 64bit binaries are provided for macOS, and the minimum macOS version
 supported is macOS 10.10 (Yosemite).
 
+Native support for Apple Silicon (`arm64`) devices was added in Electron 11.0.0.
+
 ### Windows
 
 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