chore: fix spelling errors in multiple files (#34574)

* chore: fix spelling in .circleci

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in BUILD.gn

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in appveyor.yml

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in build

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in docs

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in lib

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in script

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in shell

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in spec

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

* chore: fix spelling in spec-main

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
This commit is contained in:
Josh Soref 2022-06-16 03:46:11 -04:00 committed by GitHub
parent f418a49857
commit ea4278754c
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
58 changed files with 88 additions and 88 deletions

View file

@ -1381,7 +1381,7 @@ method returns false. If we fail to perform the copy, then this method will
throw an error. The message in the error should be informative and tell
you exactly what went wrong.
By default, if an app of the same name as the one being moved exists in the Applications directory and is _not_ running, the existing app will be trashed and the active app moved into its place. If it _is_ running, the pre-existing running app will assume focus and the previously active app will quit itself. This behavior can be changed by providing the optional conflict handler, where the boolean returned by the handler determines whether or not the move conflict is resolved with default behavior. i.e. returning `false` will ensure no further action is taken, returning `true` will result in the default behavior and the method continuing.
By default, if an app of the same name as the one being moved exists in the Applications directory and is _not_ running, the existing app will be trashed and the active app moved into its place. If it _is_ running, the preexisting running app will assume focus and the previously active app will quit itself. This behavior can be changed by providing the optional conflict handler, where the boolean returned by the handler determines whether or not the move conflict is resolved with default behavior. i.e. returning `false` will ensure no further action is taken, returning `true` will result in the default behavior and the method continuing.
For example:

View file

@ -713,7 +713,7 @@ To clear the handler, call `setDevicePermissionHandler(null)`.
This handler can be used to provide default permissioning to devices without first calling for permission
to devices (eg via `navigator.hid.requestDevice`). If this handler is not defined, the default device
permissions as granted through device selection (eg via `navigator.hid.requestDevice`) will be used.
Additionally, the default behavior of Electron is to store granted device permision through the lifetime
Additionally, the default behavior of Electron is to store granted device permission through the lifetime
of the corresponding WebContents. If longer term storage is needed, a developer can store granted device
permissions (eg when handling the `select-hid-device` event) and then read from that storage with `setDevicePermissionHandler`.

View file

@ -64,7 +64,7 @@ If you want to add a new API module to Electron, you'll want to look in [creatin
Electron has a fully-fledged governance system that oversees activity in Electron and whose working groups are responsible for areas like APIs, releases, and upgrades to Electron's dependencies including Chromium and Node.js. Depending on how frequently and to what end you want to contribute, you may want to consider joining a working group.
Details about each group and their reponsibilities can be found in the [governance repo](https://github.com/electron/governance).
Details about each group and their responsibilities can be found in the [governance repo](https://github.com/electron/governance).
## Patches in Electron

View file

@ -9,7 +9,7 @@ Some of the more common approaches are outlined below.
Chromium contains logging macros which can aid debugging by printing information to console in C++ and Objective-C++.
You might use this to print out variable values, function names, and line numbers, amonst other things.
You might use this to print out variable values, function names, and line numbers, amongst other things.
Some examples:
@ -25,7 +25,7 @@ See [logging.h](https://chromium.googlesource.com/chromium/src/base/+/refs/heads
## Printing Stacktraces
Chromium contains a helper to print stack traces to console without interrrupting the program.
Chromium contains a helper to print stack traces to console without interrupting the program.
```cpp
#include "base/debug/stack_trace.h"

View file

@ -43,7 +43,7 @@ the WebHID API:
* [`ses.setDevicePermissionHandler(handler)`](../api/session.md#sessetdevicepermissionhandlerhandler)
can be used to provide default permissioning to devices without first calling
for permission to devices via `navigator.hid.requestDevice`. Additionally,
the default behavior of Electron is to store granted device permision through
the default behavior of Electron is to store granted device permission through
the lifetime of the corresponding WebContents. If longer term storage is
needed, a developer can store granted device permissions (eg when handling
the `select-hid-device` event) and then read from that storage with
@ -92,7 +92,7 @@ There are several additional APIs for working with the Web Serial API:
* [`ses.setDevicePermissionHandler(handler)`](../api/session.md#sessetdevicepermissionhandlerhandler)
can be used to provide default permissioning to devices without first calling
for permission to devices via `navigator.serial.requestPort`. Additionally,
the default behavior of Electron is to store granted device permision through
the default behavior of Electron is to store granted device permission through
the lifetime of the corresponding WebContents. If longer term storage is
needed, a developer can store granted device permissions (eg when handling
the `select-serial-port` event) and then read from that storage with

View file

@ -18,7 +18,7 @@ npm install --save-dev electron@latest
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 the the [SemVer](#semver) spec
1. Strict use of the [SemVer](#semver) spec
2. Introduction of semver-compliant `-beta` tags
3. Introduction of [conventional commit messages](https://conventionalcommits.org/)
4. Well-defined stabilization branches