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:
parent
f418a49857
commit
ea4278754c
58 changed files with 88 additions and 88 deletions
|
@ -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:
|
||||
|
||||
|
|
|
@ -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`.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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"
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue