mirror of
https://github.com/electron/electron.git
synced 2026-02-26 03:01:17 -05:00
Compare commits
1 Commits
roller/nod
...
verify-com
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
15c922db68 |
@@ -7,13 +7,14 @@ description: Guide for performing Chromium version upgrades in the Electron proj
|
||||
|
||||
## Summary
|
||||
|
||||
Run `e sync --3` repeatedly, fixing patch conflicts as they arise, until it succeeds. Then export patches and commit changes atomically.
|
||||
Run `e sync --3` repeatedly, fixing patch conflicts as they arise, until it succeeds. Then run `e patches all` and commit changes atomically.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
Phase One is complete when:
|
||||
- `e sync --3` exits with code 0 (no patch failures)
|
||||
- All changes are committed per the commit guidelines
|
||||
- `e patches all` has been run to export all changes
|
||||
- All changes are committed per the commit guidelines below
|
||||
|
||||
Do not stop until these criteria are met.
|
||||
|
||||
@@ -29,18 +30,12 @@ The `roller/chromium/main` branch is created by automation to update Electron's
|
||||
- `patches/`: Patch files organized by target
|
||||
- `docs/development/patches.md`: Patch system documentation
|
||||
|
||||
## Pre-flight Checks
|
||||
|
||||
Run these once at the start of each upgrade session:
|
||||
|
||||
1. **Clear rerere cache** (if enabled): `git rerere clear` in both the electron and `..` repos. Stale recorded resolutions from a prior attempt can silently apply wrong merges.
|
||||
2. **Ensure pre-commit hooks are installed**: Check that `.git/hooks/pre-commit` exists. If not, run `yarn husky` to install it. The hook runs `lint-staged` which handles clang-format for C++ files.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Run `e sync --3` (the `--3` flag enables 3-way merge, always required)
|
||||
2. If succeeds → skip to step 5
|
||||
3. If patch fails:
|
||||
1. Delete the `.git/rr-cache` in both the `electron` and `..` folder to ensure no accidental rerere replays occur from before this upgrade phase attempt started
|
||||
2. Run `e sync --3` (the `--3` flag enables 3-way merge, always required)
|
||||
3. If succeeds → skip to step 6
|
||||
4. If patch fails:
|
||||
- Identify target repo and patch from error output
|
||||
- Analyze failure (see references/patch-analysis.md)
|
||||
- Fix conflict in target repo's working directory
|
||||
@@ -48,8 +43,10 @@ Run these once at the start of each upgrade session:
|
||||
- Repeat until all patches for that repo apply
|
||||
- IMPORTANT: Once `git am --continue` succeeds you MUST run `e patches {target}` to export fixes
|
||||
- Return to step 1
|
||||
4. When `e sync --3` succeeds, run `e patches all`
|
||||
5. **Read `references/phase-one-commit-guidelines.md` NOW**, then commit changes following those instructions exactly.
|
||||
5. When `e sync --3` succeeds, run `e patches all`
|
||||
6. **Read `references/phase-one-commit-guidelines.md` NOW**, then commit changes following those instructions exactly.
|
||||
|
||||
Before committing any Phase One changes, you MUST read `references/phase-one-commit-guidelines.md` and follow its instructions exactly.
|
||||
|
||||
## Commands Reference
|
||||
|
||||
@@ -59,7 +56,6 @@ Run these once at the start of each upgrade session:
|
||||
| `git am --continue` | Continue after resolving conflict (run in target repo) |
|
||||
| `e patches {target}` | Export commits from target repo to patch files |
|
||||
| `e patches all` | Export all patches from all targets |
|
||||
| `e patches {target} --commit-updates` | Export patches and auto-commit trivial changes |
|
||||
| `e patches --list-targets` | List targets and config paths |
|
||||
|
||||
## Patch System Mental Model
|
||||
@@ -85,20 +81,24 @@ Fix existing patches 99% of the time rather than creating new ones.
|
||||
2. **Never change TODO assignees**: `TODO(name)` must retain original name
|
||||
3. **Update descriptions**: If upstream changed (e.g., `DCHECK` → `CHECK_IS_TEST`), update patch commit message to reflect current state
|
||||
|
||||
## Final Deliverable
|
||||
|
||||
After Phase One, write a summary of every change: what was fixed, why, reasoning, and Chromium CL links.
|
||||
|
||||
# Electron Chromium Upgrade: Phase Two
|
||||
|
||||
## Summary
|
||||
|
||||
Run `e build -k 999 -- --quiet` repeatedly, fixing build issues as they arise, until it succeeds. Then run `e start --version` to validate Electron launches and commit changes atomically.
|
||||
Run `e build -k 999` repeatedly, fixing build issues as they arise, until it succeeds. Then run `e start --version` to validate Electron launches and commit changes atomically.
|
||||
|
||||
Run Phase Two immediately after Phase One is complete.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
Phase Two is complete when:
|
||||
- `e build -k 999 -- --quiet` exits with code 0 (no build failures)
|
||||
- `e build -k 999` exits with code 0 (no build failures)
|
||||
- `e start --version` has been run to check Electron launches
|
||||
- All changes are committed per the commit guidelines
|
||||
- All changes are committed per the commit guidelines below
|
||||
|
||||
Do not stop until these criteria are met. Do not delete code or features, never comment out code in order to take short cut. Make all existing code, logic and intention work.
|
||||
|
||||
@@ -112,7 +112,8 @@ The `roller/chromium/main` branch is created by automation to update Electron's
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Run `e build -k 999 -- --quiet` (the `--quiet` flag suppresses per-target status lines, showing only errors and the final result)
|
||||
1. Run `e build -k 999` (the `-k 999` flag is a flag to ninja to say "do not stop until you find that many errors" it is an attempt to get as much error
|
||||
context as possible for each time we run build)
|
||||
2. If succeeds → skip to step 6
|
||||
3. If build fails:
|
||||
- Identify underlying file in "electron" from the compilation error message
|
||||
@@ -125,17 +126,27 @@ The `roller/chromium/main` branch is created by automation to update Electron's
|
||||
4. **CRITICAL**: After ANY commit (especially patch commits), immediately run `git status` in the electron repo
|
||||
- Look for other modified `.patch` files that only have index/hunk header changes
|
||||
- These are dependent patches affected by your fix
|
||||
- Commit them immediately with: `git commit -am "chore: update patches (trivial only)"`
|
||||
- Commit them immediately with: `git commit -am "chore: update patch hunk headers"`
|
||||
- This prevents losing track of necessary updates
|
||||
5. Return to step 1
|
||||
6. When `e build` succeeds, run `e start --version`
|
||||
7. Check if you have any pending changes in the Chromium repo by running `git status`
|
||||
- If you have changes follow the instructions below in "A. Patch Fixes" to correctly commit those modifications into the appropriate patch file
|
||||
|
||||
Before committing any Phase Two changes, you MUST read `references/phase-two-commit-guidelines.md` and follow its instructions exactly.
|
||||
|
||||
## Build Error Detection
|
||||
|
||||
When monitoring `e build -k 999` output, filter for errors using this regex pattern:
|
||||
error:|FAILED:|fatal:|subcommand failed|build finished
|
||||
|
||||
The build output is extremely verbose. Filtering is essential to catch errors quickly.
|
||||
|
||||
## Commands Reference
|
||||
|
||||
| Command | Purpose |
|
||||
|---------|---------|
|
||||
| `e build -k 999 -- --quiet` | Build Electron, continue on errors, suppress status lines |
|
||||
| `e build -k 999` | Builds Electron and won't stop until either all targets attempted or 999 errors found |
|
||||
| `e build -t {target}.o` | Build just one specific target to verify a fix |
|
||||
| `e start --version` | Validate Electron launches after successful build |
|
||||
|
||||
@@ -152,21 +163,28 @@ When the error is in a file that Electron patches (check with `grep -l "filename
|
||||
git add <modified-file>
|
||||
git commit --fixup=<original-patch-commit-hash>
|
||||
GIT_SEQUENCE_EDITOR=: git rebase --autosquash --autostash -i <commit>^
|
||||
```
|
||||
3. Export the updated patch: `e patches chromium`
|
||||
4. Commit the updated patch file following `references/phase-one-commit-guidelines.md`.
|
||||
3. Export the updated patch: e patches chromium
|
||||
4. Commit the updated patch file in the electron repo following the `references/phase-one-commit-guidelines.md`, then commit changes following those instructions exactly. **READ THESE GUIDELINES BEFORE COMMITTING THESE CHANGES**
|
||||
|
||||
To find the original patch commit to fixup: `git log --oneline | grep -i "keyword from patch name"`
|
||||
|
||||
The base commit for rebase is the Chromium commit before patches were applied. Find it by checking the `refs/patches/upstream-head` ref.
|
||||
|
||||
### B. Electron Code Fixes (for files in shell/, electron/, etc.)
|
||||
B. Electron Code Fixes (for files in shell/, electron/, etc.)
|
||||
|
||||
When the error is in Electron's own source code:
|
||||
|
||||
1. Edit files directly in the electron repo
|
||||
2. Commit directly (no patch export needed)
|
||||
|
||||
Dependent Patch Updates
|
||||
|
||||
IMPORTANT: When you modify a patch, other patches that apply to the same file may have their hunk headers invalidated. After committing a patch fix:
|
||||
|
||||
1. Run git status in the electron repo
|
||||
2. Look for other modified .patch files with just index/hunk header changes
|
||||
3. Commit these with: git commit -m "chore: update patch hunk headers"
|
||||
|
||||
# Critical: Read Before Committing
|
||||
|
||||
- Before ANY Phase One commits: Read `references/phase-one-commit-guidelines.md`
|
||||
@@ -178,4 +196,4 @@ This skill has additional reference files in `references/`:
|
||||
- phase-one-commit-guidelines.md - Commit format for Phase One
|
||||
- phase-two-commit-guidelines.md - Commit format for Phase Two
|
||||
|
||||
Read these when referenced in the workflow steps.
|
||||
Read these when referenced in the workflow steps.
|
||||
@@ -17,56 +17,6 @@
|
||||
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/{CL_NUMBER}
|
||||
```
|
||||
|
||||
## Critical: Resolve by Intent, Not by Mechanical Merge
|
||||
|
||||
When resolving a patch conflict, do NOT blindly preserve the patch's old code. Instead:
|
||||
|
||||
1. **Understand the upstream CL's full scope** — not just the conflicting hunk.
|
||||
Run `git show <commit> --stat` and read diffs for all affected files.
|
||||
Upstream may have removed structs, members, or methods that the patch
|
||||
references in other hunks or files.
|
||||
|
||||
2. **Re-read the patch commit message** to understand its *intent* — what
|
||||
behavior does it need to preserve or add?
|
||||
|
||||
3. **Implement the intent against the new upstream code.** If the patch's
|
||||
purpose is "add a feature flag guard", add only the guard — don't also
|
||||
restore old code inside the guard that upstream separately removed.
|
||||
|
||||
### Lesson: Upstream Removals Break Patch References
|
||||
|
||||
- **Trigger:** Patch conflict involves an upstream refactor (not just context drift)
|
||||
- **Strategy:** After identifying the upstream CL, check its full diff for
|
||||
removed types, members, and methods. If the patch's old code references
|
||||
something removed, the resolution must use the new upstream mechanism.
|
||||
- **Evidence:** An upstream CL removed a `HeadlessModeWindow` struct from a
|
||||
header, but the conflict was only in a `.mm` file. Mechanically keeping the
|
||||
patch's old line (`headless_mode_window_ = ...`) produced code referencing
|
||||
a nonexistent type — caught only on review, not at patch-apply time.
|
||||
|
||||
### Lesson: Separate Patch Purpose from Patch Implementation
|
||||
|
||||
- **Trigger:** Conflict between "upstream simplified code" vs "patch has older code"
|
||||
- **Strategy:** Identify the *minimal* change the patch needs. If the patch
|
||||
wraps code in a conditional, only add the conditional — don't restore old
|
||||
code that was inside the conditional but was separately cleaned up upstream.
|
||||
- **Evidence:** An occlusion patch needed only a feature flag check, but the
|
||||
old patch also contained a version check that upstream intentionally removed.
|
||||
Mechanically preserving the old patch code re-added the removed check.
|
||||
|
||||
### Lesson: Finish the Adaptation at Conflict Time
|
||||
|
||||
- **Trigger:** A patch conflict involves an upstream API removal or replacement
|
||||
- **Strategy:** When resolving the conflict, fully adapt the patch to use the
|
||||
new API in the same commit. Don't remove the old code and leave behind stale
|
||||
references that will "be fixed in Phase Two." Each patch fix commit should be
|
||||
a complete resolution.
|
||||
- **Evidence:** A safestorage patch conflicted because Chromium removed Keychain V1.
|
||||
The conflict was resolved by removing V1 hunks, but the remaining code still
|
||||
called V1 methods (`FindGenericPassword` with 3 args, `ItemDelete` with
|
||||
`SecKeychainItemRef`). These should have been adapted to V2 APIs in the same
|
||||
commit, not deferred.
|
||||
|
||||
## Common Failure Patterns
|
||||
|
||||
| Pattern | Cause | Solution |
|
||||
|
||||
@@ -4,65 +4,19 @@ Only follow these instructions if there are uncommitted changes to `patches/` af
|
||||
|
||||
Ignore other instructions about making commit messages, our guidelines are CRITICALLY IMPORTANT and must be followed.
|
||||
|
||||
## Each Commit Must Be Complete
|
||||
|
||||
When resolving a patch conflict, fully adapt the patch to the new upstream code in the same commit. If the upstream change removes an API the patch uses, update the patch to use the replacement API now — don't leave stale references knowing they'll need fixing later. The goal is that each commit represents a finished resolution, not a partial one that defers known work to a future phase.
|
||||
|
||||
## Commit Message Style
|
||||
|
||||
**Titles** follow the 60/80-character guideline: simple changes fit within 60 characters, otherwise the limit is 80 characters.
|
||||
|
||||
Always include a `Co-Authored-By` trailer identifying the AI model that assisted (e.g., `Co-Authored-By: <AI model attribution>`).
|
||||
|
||||
### Patch conflict fixes
|
||||
|
||||
Use `fix(patch):` prefix. The title should name the upstream change, not your response to it:
|
||||
|
||||
```
|
||||
fix(patch): {topic headline}
|
||||
|
||||
Ref: {Chromium CL link}
|
||||
|
||||
Co-Authored-By: <AI model attribution>
|
||||
```
|
||||
|
||||
Only add a description body if it provides clarity beyond the title. For straightforward context drift or simple API renames, the title + Ref is sufficient.
|
||||
|
||||
Examples:
|
||||
- `fix(patch): constant moved to header`
|
||||
- `fix(patch): headless mode refactor upstream`
|
||||
- `fix(patch): V1 Keychain removal`
|
||||
|
||||
### Upstreamed patch removal
|
||||
|
||||
When patches are no longer needed (applied cleanly with "already applied" or confirmed upstreamed), group ALL removals into a single commit:
|
||||
|
||||
```
|
||||
chore: remove upstreamed patch
|
||||
```
|
||||
|
||||
or (if multiple):
|
||||
|
||||
```
|
||||
chore: remove upstreamed patches
|
||||
```
|
||||
|
||||
If the patch file did NOT contain a `Reviewed-on: https://chromium-review.googlesource.com/c/chromium/...` link, add a `Ref:` in the commit. If it did (i.e. cherry-picks), no `Ref:` is needed.
|
||||
|
||||
### Trivial patch updates
|
||||
|
||||
After all fix commits, stage remaining trivial changes (index, line numbers, context only):
|
||||
|
||||
```bash
|
||||
git add patches
|
||||
git commit -m "chore: update patches (trivial only)"
|
||||
```
|
||||
|
||||
**Conflict resolution can produce trivial results.** A `git am` conflict doesn't always mean the patch content changed — context drift alone can cause a conflict. After resolving and exporting, inspect the patch diff: if only index hashes, line numbers, and context lines changed (not the patch's own `+`/`-` lines), it's trivial and belongs here, not in a `fix(patch):` commit.
|
||||
|
||||
## Atomic Commits
|
||||
|
||||
Each patch conflict fix gets its own commit with its own Ref.
|
||||
For each fix made to a patch, create a separate commit:
|
||||
|
||||
```
|
||||
fix(patch-conflict): {concise title}
|
||||
|
||||
{Brief explanation, 1-2 paragraphs max}
|
||||
|
||||
Ref: {Chromium CL link}
|
||||
```
|
||||
|
||||
IMPORTANT: Ensure that any changes made to patch content as a result of a change in Chromium is committed individually. Each change should have it's own commit message and it's own REF.
|
||||
|
||||
IMPORTANT: Try really hard to find the CL reference per the instructions below. Each change you made should in theory have been in response to a change made in Chromium that you identified or can identify. Try for a while to identify and include the ref in the commit message. Do not give up easily.
|
||||
|
||||
@@ -76,27 +30,23 @@ Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/XXXXXXX
|
||||
|
||||
If no CL found after searching: `Ref: Unable to locate CL`
|
||||
|
||||
## Example Commits
|
||||
## Final Cleanup
|
||||
|
||||
### Patch conflict fix (simple — title is sufficient)
|
||||
After all fix commits, stage remaining changes:
|
||||
|
||||
```
|
||||
fix(patch): constant moved to header
|
||||
|
||||
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7536483
|
||||
|
||||
Co-Authored-By: <AI model attribution>
|
||||
```bash
|
||||
git add patches
|
||||
git commit -m "chore: update patch hunk headers"
|
||||
```
|
||||
|
||||
### Patch conflict fix (complex — description adds value)
|
||||
## Example Commit
|
||||
|
||||
```
|
||||
fix(patch): V1 Keychain removal
|
||||
fix(patch-conflict): update web_contents_impl.cc context for navigation refactor
|
||||
|
||||
Upstream deleted the V1 Keychain API. Removed V1 hunks and adapted
|
||||
keychain_password_mac.mm to use KeychainV2 APIs.
|
||||
The upstream navigation code was refactored to use NavigationRequest directly
|
||||
instead of going through NavigationController. Updated surrounding context
|
||||
to match new code structure.
|
||||
|
||||
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7540447
|
||||
|
||||
Co-Authored-By: <AI model attribution>
|
||||
```
|
||||
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/1234567
|
||||
```
|
||||
@@ -4,37 +4,41 @@ Only follow these instructions if there are uncommitted changes in the Electron
|
||||
|
||||
Ignore other instructions about making commit messages, our guidelines are CRITICALLY IMPORTANT and must be followed.
|
||||
|
||||
## Commit Message Style
|
||||
|
||||
**Titles** follow the 60/80-character guideline: simple changes fit within 60 characters, otherwise the limit is 80 characters. Exception: upstream Chromium CL titles are used verbatim even if longer.
|
||||
|
||||
Always include a `Co-Authored-By` trailer identifying the AI model that assisted (e.g., `Co-Authored-By: <AI model attribution>`).
|
||||
|
||||
## Two Commit Types
|
||||
|
||||
### For Electron Source Changes (shell/, electron/, etc.)
|
||||
|
||||
```
|
||||
{CL-Number}: {upstream CL's original title}
|
||||
{CL-Number}: {concise description of API change}
|
||||
|
||||
{Brief explanation of what upstream changed and how Electron was adapted}
|
||||
|
||||
Ref: {Chromium CL link}
|
||||
|
||||
Co-Authored-By: <AI model attribution>
|
||||
```
|
||||
|
||||
Use the **upstream CL's original commit title** — do not paraphrase or rewrite it. To find it: `git log -1 --format=%s <chromium-commit-hash>`.
|
||||
IMPORTANT: Ensure that any change made to electron as a result of a change in Chromium is committed individually. Each change should have it's own commit message and it's own REF. Logically grouped into commits that make sense rather than one giant commit.
|
||||
|
||||
Only add a description body if it provides clarity beyond what the title already says (e.g., when Electron's adaptation is non-obvious). For simple renames, method additions, or straightforward API updates, the title + Ref link is sufficient.
|
||||
IMPORTANT: Try really hard to find the CL reference per the instructions below. Each change you made should in theory have been in response to a change made in Chromium that you identified or can identify. Try for a while to identify and include the ref in the commit message. Do not give up easily.
|
||||
|
||||
Each change should have its own commit and its own Ref. Logically group into commits that make sense rather than one giant commit. You may include multiple "Ref" links if required.
|
||||
You may include multiple "Ref" links if required.
|
||||
|
||||
For a CL link in the format `https://chromium-review.googlesource.com/c/chromium/src/+/2958369` the "CL-Number" is `2958369`.
|
||||
|
||||
IMPORTANT: Try really hard to find the CL reference. Each change you made should in theory have been in response to a change in Chromium. Do not give up easily.
|
||||
For a CL link in the format `https://chromium-review.googlesource.com/c/chromium/src/+/2958369` the "CL-Number" is `2958369`
|
||||
|
||||
### For Patch Updates (patches/chromium/*.patch)
|
||||
|
||||
Use the same fixup workflow as Phase One and follow `references/phase-one-commit-guidelines.md` for the commit message format (`fix(patch):` prefix, topic style).
|
||||
Use the same fixup workflow as Phase One:
|
||||
1. Fix in Chromium source tree
|
||||
2. Fixup commit + rebase
|
||||
3. Export with `e patches chromium`
|
||||
4. Commit the patch file:
|
||||
|
||||
```
|
||||
fix(patch-update): {concise description}
|
||||
|
||||
{Brief explanation}
|
||||
|
||||
Ref: {Chromium CL link}
|
||||
```
|
||||
|
||||
## Dependent Patch Header Updates
|
||||
|
||||
@@ -42,43 +46,37 @@ After any patch modification, check for other affected patches:
|
||||
|
||||
```bash
|
||||
git status
|
||||
# If other .patch files show as modified with only index, line number, and context changes:
|
||||
# If other .patch files show as modified with only hunk header changes:
|
||||
git add patches/
|
||||
git commit -m "chore: update patches (trivial only)"
|
||||
git commit -m "chore: update patch hunk headers"
|
||||
```
|
||||
|
||||
## Finding CL References
|
||||
|
||||
Use git log or git blame on Chromium source files. Look for:
|
||||
|
||||
```
|
||||
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/XXXXXXX
|
||||
```
|
||||
|
||||
If no CL found after searching: `Ref: Unable to locate CL`
|
||||
If no CL found after searching: Ref: Unable to locate CL
|
||||
|
||||
## Example Commits
|
||||
|
||||
### Electron Source Fix (simple — title is self-explanatory)
|
||||
### Electron Source Fix
|
||||
|
||||
```
|
||||
7535923: Rename ozone buildflags
|
||||
fix: update GetPlugins to GetPluginsAsync for API change
|
||||
|
||||
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7535923
|
||||
The upstream Chromium API changed:
|
||||
- Old: GetPlugins(callback) - took a callback
|
||||
- New: GetPluginsAsync(callback) - async version takes a callback
|
||||
|
||||
Co-Authored-By: <AI model attribution>
|
||||
```
|
||||
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/1234567
|
||||
|
||||
### Electron Source Fix (complex — description adds value)
|
||||
### Patch Fix
|
||||
|
||||
```
|
||||
7534194: Convert some functions in ui::Clipboard to async
|
||||
fix(patch-conflict): update picture-in-picture for gesture handling refactor
|
||||
|
||||
Adapted ExtractCustomPlatformNames calls to use RunLoop pattern
|
||||
consistent with existing ReadImage implementation, since upstream
|
||||
converted the API from synchronous return to callback-based.
|
||||
Upstream added new gesture handling code that accesses live caption dialog.
|
||||
The live caption functionality is disabled in Electron's patch, so wrapped
|
||||
the new code in #if 0 guards to match existing pattern.
|
||||
|
||||
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7534194
|
||||
|
||||
Co-Authored-By: <AI model attribution>
|
||||
```
|
||||
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7654321
|
||||
|
||||
1
.github/PULL_REQUEST_TEMPLATE.md
vendored
1
.github/PULL_REQUEST_TEMPLATE.md
vendored
@@ -12,6 +12,7 @@ Contributors guide: https://github.com/electron/electron/blob/main/CONTRIBUTING.
|
||||
|
||||
- [ ] PR description included
|
||||
- [ ] I have built and tested this PR
|
||||
- [ ] [Commits are signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key)
|
||||
- [ ] `npm test` passes
|
||||
- [ ] tests are [changed or added](https://github.com/electron/electron/blob/main/docs/development/testing.md)
|
||||
- [ ] relevant API documentation, tutorials, and examples are updated and follow the [documentation style guide](https://github.com/electron/electron/blob/main/docs/development/style-guide.md)
|
||||
|
||||
2
.github/actions/build-electron/action.yml
vendored
2
.github/actions/build-electron/action.yml
vendored
@@ -98,7 +98,7 @@ runs:
|
||||
# Upload build stats to Datadog
|
||||
if ($env:DD_API_KEY) {
|
||||
try {
|
||||
npx node electron\script\build-stats.mjs out\Default\siso.exe.INFO --upload-stats ; $LASTEXITCODE = 0
|
||||
npx node electron\script\build-stats.mjs out\Default\siso.exe.INFO --upload-stats
|
||||
} catch {
|
||||
Write-Host "Build stats upload failed, continuing..."
|
||||
}
|
||||
|
||||
@@ -15,7 +15,7 @@ runs:
|
||||
git config --global core.preloadindex true
|
||||
git config --global core.longpaths true
|
||||
fi
|
||||
export BUILD_TOOLS_SHA=a0cc95a1884a631559bcca0c948465b725d9295a
|
||||
export BUILD_TOOLS_SHA=4430e4a505e0f4fa2a41b707a10a36f780bbdd26
|
||||
npm i -g @electron/build-tools
|
||||
# Update depot_tools to ensure python
|
||||
e d update_depot_tools
|
||||
|
||||
122
.github/copilot-instructions.md
vendored
122
.github/copilot-instructions.md
vendored
@@ -1,122 +0,0 @@
|
||||
# Copilot Instructions for Electron
|
||||
|
||||
## Build System
|
||||
|
||||
Electron uses `@electron/build-tools` (`e` CLI). Install with `npm i -g @electron/build-tools`.
|
||||
|
||||
```bash
|
||||
e sync # Fetch sources and apply patches
|
||||
e build # Build Electron (GN + Ninja)
|
||||
e build -k 999 # Build, continuing through errors
|
||||
e start # Run built Electron
|
||||
e start --version # Verify Electron launches
|
||||
e test # Run full test suite
|
||||
e debug # Run in debugger (lldb on macOS, gdb on Linux)
|
||||
```
|
||||
|
||||
### Linting
|
||||
|
||||
```bash
|
||||
npm run lint # Run all linters (JS, C++, Python, GN, docs)
|
||||
npm run lint:js # JavaScript/TypeScript only
|
||||
npm run lint:clang-format # C++ formatting only
|
||||
npm run lint:cpp # C++ linting only
|
||||
npm run lint:docs # Documentation only
|
||||
```
|
||||
|
||||
### Running a Single Test
|
||||
|
||||
```bash
|
||||
npm run test -- -g "pattern" # Run tests matching a regex pattern
|
||||
# Example: npm run test -- -g "ipc"
|
||||
```
|
||||
|
||||
### Running a Single Node.js Test
|
||||
|
||||
```bash
|
||||
node script/node-spec-runner.js parallel/test-crypto-keygen
|
||||
```
|
||||
|
||||
## Architecture
|
||||
|
||||
Electron embeds Chromium (rendering) and Node.js (backend) to enable desktop apps with web technologies. The parent directory (`../`) is the Chromium source tree.
|
||||
|
||||
### Process Model
|
||||
|
||||
Electron has two primary process types, mirroring Chromium:
|
||||
|
||||
- **Main process** (`shell/browser/` + `lib/browser/`): Controls app lifecycle, creates windows, system APIs
|
||||
- **Renderer process** (`shell/renderer/` + `lib/renderer/`): Runs web content in BrowserWindows
|
||||
|
||||
### Native ↔ JavaScript Bridge
|
||||
|
||||
Each API is implemented as a C++/JS pair:
|
||||
|
||||
- C++ side: `shell/browser/api/electron_api_{name}.cc/.h` — uses `gin::Wrappable` and `ObjectTemplateBuilder`
|
||||
- JS side: `lib/browser/api/{name}.ts` — exports the module, registered in `lib/browser/api/module-list.ts`
|
||||
- Binding: `NODE_LINKED_BINDING_CONTEXT_AWARE(electron_browser_{name}, Initialize)` in C++ and registered in `shell/common/node_bindings.cc`
|
||||
- Type declaration: `typings/internal-ambient.d.ts` maps `process._linkedBinding('electron_browser_{name}')`
|
||||
|
||||
### Patches System
|
||||
|
||||
Electron patches upstream dependencies (Chromium, Node.js, V8, etc.) rather than forking them. Patches live in `patches/` organized by target, with `patches/config.json` mapping directories to repos.
|
||||
|
||||
```text
|
||||
patches/{target}/*.patch → [e sync] → target repo commits
|
||||
← [e patches] ←
|
||||
```
|
||||
|
||||
Key rules:
|
||||
|
||||
- Fix existing patches rather than creating new ones
|
||||
- Preserve original authorship in TODO comments — never change `TODO(name)` assignees
|
||||
- Each patch commit message must explain why the patch exists
|
||||
- After modifying patches, run `e patches {target}` to export
|
||||
|
||||
When working on the `roller/chromium/main` branch for Chromium upgrades, use `e sync --3` for 3-way merge conflict resolution.
|
||||
|
||||
## Conventions
|
||||
|
||||
### File Naming
|
||||
|
||||
- JS/TS files: kebab-case (`file-name.ts`)
|
||||
- C++ files: snake_case with `electron_api_` prefix (`electron_api_safe_storage.cc`)
|
||||
- Test files: `api-{module-name}-spec.ts` in `spec/`
|
||||
- Source file lists are maintained in `filenames.gni` (with platform-specific sections)
|
||||
|
||||
### JavaScript/TypeScript
|
||||
|
||||
- Semicolons required (`"semi": ["error", "always"]`)
|
||||
- `const` and `let` only (no `var`)
|
||||
- Arrow functions preferred
|
||||
- Import order enforced: `@electron/internal` → `@electron` → `electron` → external → builtin → relative
|
||||
- API naming: `PascalCase` for classes (`BrowserWindow`), `camelCase` for module APIs (`globalShortcut`)
|
||||
- Prefer getters/setters over jQuery-style `.text([text])` patterns
|
||||
|
||||
### C++
|
||||
|
||||
- Follows Chromium coding style, enforced by `clang-format` and `clang-tidy`
|
||||
- Uses Chromium abstractions (`base::`, `content::`, etc.)
|
||||
- Header guards: `#ifndef ELECTRON_SHELL_BROWSER_API_ELECTRON_API_{NAME}_H_`
|
||||
- Platform-specific files: `_mac.mm`, `_win.cc`, `_linux.cc`
|
||||
|
||||
### Testing
|
||||
|
||||
- Framework: Mocha + Chai + Sinon
|
||||
- Test helpers in `spec/lib/` (e.g., `spec-helpers.ts`, `window-helpers.ts`)
|
||||
- Use `defer()` from spec-helpers for cleanup, `closeAllWindows()` for window teardown
|
||||
- Tests import from `electron/main` or `electron/renderer`
|
||||
|
||||
### Documentation
|
||||
|
||||
- API docs in `docs/api/` as Markdown, parsed by `@electron/docs-parser` to generate `electron.d.ts`
|
||||
- API history tracked via YAML blocks in HTML comments within doc files
|
||||
- Docs must pass `npm run lint:docs`
|
||||
|
||||
### Build Configuration
|
||||
|
||||
- `BUILD.gn`: Main GN build config
|
||||
- `buildflags/buildflags.gni`: Feature flags (PDF viewer, extensions, spellchecker)
|
||||
- `build/args/`: Build argument profiles (`testing.gn`, `release.gn`, `all.gn`)
|
||||
- `DEPS`: Dependency versions and checkout paths
|
||||
- `chromium_src/`: Chromium source file overrides (compiled instead of originals)
|
||||
16
.github/problem-matchers/markdownlint.json
vendored
16
.github/problem-matchers/markdownlint.json
vendored
@@ -1,16 +0,0 @@
|
||||
{
|
||||
"problemMatcher": [
|
||||
{
|
||||
"owner": "markdownlint",
|
||||
"pattern": [
|
||||
{
|
||||
"regexp": "^(.+):(\\d+):(\\d+)\\s+(.*)$",
|
||||
"file": 1,
|
||||
"line": 2,
|
||||
"column": 3,
|
||||
"message": 4
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
63
.github/workflows/issue-commented.yml
vendored
63
.github/workflows/issue-commented.yml
vendored
@@ -1,4 +1,4 @@
|
||||
name: Issue / Pull Request Commented
|
||||
name: Issue Commented
|
||||
|
||||
on:
|
||||
issue_comment:
|
||||
@@ -8,16 +8,16 @@ on:
|
||||
permissions: {}
|
||||
|
||||
jobs:
|
||||
blocked-issue-commented:
|
||||
issue-commented:
|
||||
name: Remove blocked/{need-info,need-repro} on comment
|
||||
if: ${{ !github.event.issue.pull_request && (contains(github.event.issue.labels.*.name, 'blocked/need-repro') || contains(github.event.issue.labels.*.name, 'blocked/need-info ❌')) && github.event.comment.user.type != 'Bot' }}
|
||||
runs-on: ubuntu-slim
|
||||
if: ${{ (contains(github.event.issue.labels.*.name, 'blocked/need-repro') || contains(github.event.issue.labels.*.name, 'blocked/need-info ❌')) && github.event.comment.user.type != 'Bot' }}
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Get author association
|
||||
id: get-author-association
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
run: &get-author-association |
|
||||
run: |
|
||||
AUTHOR_ASSOCIATION=$(gh api /repos/electron/electron/issues/comments/${{ github.event.comment.id }} --jq '.author_association')
|
||||
echo "author_association=$AUTHOR_ASSOCIATION" >> "$GITHUB_OUTPUT"
|
||||
- name: Generate GitHub App token
|
||||
@@ -33,56 +33,3 @@ jobs:
|
||||
ISSUE_URL: ${{ github.event.issue.html_url }}
|
||||
run: |
|
||||
gh issue edit $ISSUE_URL --remove-label 'blocked/need-repro','blocked/need-info ❌'
|
||||
|
||||
pr-reviewer-requested:
|
||||
name: Maintainer requested reviewer on PR
|
||||
if: ${{ github.event.issue.pull_request && startsWith(github.event.comment.body, '/request-review') && github.event.comment.user.type != 'Bot' }}
|
||||
runs-on: ubuntu-slim
|
||||
steps:
|
||||
- name: Get author association
|
||||
id: get-author-association
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
run: *get-author-association
|
||||
- name: Generate GitHub App token
|
||||
uses: electron/github-app-auth-action@e14e47722ed120360649d0789e25b9baece12725 # v2.0.0
|
||||
if: ${{ contains(fromJSON('["MEMBER", "OWNER"]'), steps.get-author-association.outputs.author_association) }}
|
||||
id: generate-token
|
||||
with:
|
||||
creds: ${{ secrets.ISSUE_TRIAGE_GH_APP_CREDS }}
|
||||
- name: Request reviewer
|
||||
if: ${{ contains(fromJSON('["MEMBER", "OWNER"]'), steps.get-author-association.outputs.author_association) }}
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ steps.generate-token.outputs.token }}
|
||||
PR_URL: ${{ github.event.issue.html_url }}
|
||||
COMMENT_BODY: ${{ github.event.comment.body }}
|
||||
run: |
|
||||
RAW=$(echo "$COMMENT_BODY" | head -n 1 | sed 's|/request-review\s*||' | xargs)
|
||||
|
||||
if [ -z "$RAW" ]; then
|
||||
echo "::warning::No username provided. Usage: /request-review <username>[,<username>,...]"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
IFS=',' read -ra USERS <<< "$RAW"
|
||||
for USER in "${USERS[@]}"; do
|
||||
NAME=$(echo "$USER" | sed 's/@//g' | xargs)
|
||||
if [ -z "$NAME" ]; then
|
||||
continue
|
||||
fi
|
||||
|
||||
# Strip "electron/" prefix if present to get the bare name
|
||||
BARE_NAME=$(echo "$NAME" | sed 's|^electron/||')
|
||||
|
||||
# If the original name contained "electron/" or looks like a team slug, treat as team
|
||||
if [ "$NAME" != "$BARE_NAME" ]; then
|
||||
gh pr edit $PR_URL --add-reviewer "electron/$BARE_NAME"
|
||||
else
|
||||
if ! gh api /orgs/electron/public_members/$BARE_NAME --silent > /dev/null 2>&1; then
|
||||
echo "::warning::$BARE_NAME is not a public member of the electron organization."
|
||||
continue
|
||||
fi
|
||||
|
||||
gh pr edit $PR_URL --add-reviewer "$BARE_NAME"
|
||||
fi
|
||||
done
|
||||
|
||||
2
.github/workflows/issue-labeled.yml
vendored
2
.github/workflows/issue-labeled.yml
vendored
@@ -75,7 +75,7 @@ jobs:
|
||||
creds: ${{ secrets.ISSUE_TRIAGE_GH_APP_CREDS }}
|
||||
- name: Create comment
|
||||
if: ${{ steps.check-for-comment.outputs.SHOULD_COMMENT }}
|
||||
uses: actions-cool/issues-helper@71b62d7da76e59ff7b193904feb6e77d4dbb2777 # v3.7.6
|
||||
uses: actions-cool/issues-helper@e2ff99831a4f13625d35064e2b3dfe65c07a0396 # v3.7.5
|
||||
with:
|
||||
actions: 'create-comment'
|
||||
token: ${{ steps.generate-token.outputs.token }}
|
||||
|
||||
2
.github/workflows/issue-opened.yml
vendored
2
.github/workflows/issue-opened.yml
vendored
@@ -146,7 +146,7 @@ jobs:
|
||||
}
|
||||
- name: Create unsupported major comment
|
||||
if: ${{ steps.add-labels.outputs.unsupportedMajor }}
|
||||
uses: actions-cool/issues-helper@71b62d7da76e59ff7b193904feb6e77d4dbb2777 # v3.7.6
|
||||
uses: actions-cool/issues-helper@e2ff99831a4f13625d35064e2b3dfe65c07a0396 # v3.7.5
|
||||
with:
|
||||
actions: 'create-comment'
|
||||
token: ${{ steps.generate-token.outputs.token }}
|
||||
|
||||
3
.github/workflows/linux-publish.yml
vendored
3
.github/workflows/linux-publish.yml
vendored
@@ -46,7 +46,6 @@ jobs:
|
||||
publish-x64:
|
||||
uses: ./.github/workflows/pipeline-segment-electron-publish.yml
|
||||
permissions:
|
||||
artifact-metadata: write
|
||||
attestations: write
|
||||
contents: read
|
||||
id-token: write
|
||||
@@ -66,7 +65,6 @@ jobs:
|
||||
publish-arm:
|
||||
uses: ./.github/workflows/pipeline-segment-electron-publish.yml
|
||||
permissions:
|
||||
artifact-metadata: write
|
||||
attestations: write
|
||||
contents: read
|
||||
id-token: write
|
||||
@@ -86,7 +84,6 @@ jobs:
|
||||
publish-arm64:
|
||||
uses: ./.github/workflows/pipeline-segment-electron-publish.yml
|
||||
permissions:
|
||||
artifact-metadata: write
|
||||
attestations: write
|
||||
contents: read
|
||||
id-token: write
|
||||
|
||||
4
.github/workflows/macos-publish.yml
vendored
4
.github/workflows/macos-publish.yml
vendored
@@ -50,7 +50,6 @@ jobs:
|
||||
publish-x64-darwin:
|
||||
uses: ./.github/workflows/pipeline-segment-electron-publish.yml
|
||||
permissions:
|
||||
artifact-metadata: write
|
||||
attestations: write
|
||||
contents: read
|
||||
id-token: write
|
||||
@@ -70,7 +69,6 @@ jobs:
|
||||
publish-x64-mas:
|
||||
uses: ./.github/workflows/pipeline-segment-electron-publish.yml
|
||||
permissions:
|
||||
artifact-metadata: write
|
||||
attestations: write
|
||||
contents: read
|
||||
id-token: write
|
||||
@@ -90,7 +88,6 @@ jobs:
|
||||
publish-arm64-darwin:
|
||||
uses: ./.github/workflows/pipeline-segment-electron-publish.yml
|
||||
permissions:
|
||||
artifact-metadata: write
|
||||
attestations: write
|
||||
contents: read
|
||||
id-token: write
|
||||
@@ -110,7 +107,6 @@ jobs:
|
||||
publish-arm64-mas:
|
||||
uses: ./.github/workflows/pipeline-segment-electron-publish.yml
|
||||
permissions:
|
||||
artifact-metadata: write
|
||||
attestations: write
|
||||
contents: read
|
||||
id-token: write
|
||||
|
||||
6
.github/workflows/pipeline-electron-lint.yml
vendored
6
.github/workflows/pipeline-electron-lint.yml
vendored
@@ -65,11 +65,9 @@ jobs:
|
||||
curl -sL "https://chromium.googlesource.com/chromium/src/+/${chromium_revision}/buildtools/DEPS?format=TEXT" | base64 -d > src/buildtools/DEPS
|
||||
|
||||
gclient sync --spec="solutions=[{'name':'src/buildtools','url':None,'deps_file':'DEPS','custom_vars':{'process_deps':True},'managed':False}]"
|
||||
- name: Add problem matchers
|
||||
- name: Add ESLint problem matcher
|
||||
shell: bash
|
||||
run: |
|
||||
echo "::add-matcher::src/electron/.github/problem-matchers/eslint-stylish.json"
|
||||
echo "::add-matcher::src/electron/.github/problem-matchers/markdownlint.json"
|
||||
run: echo "::add-matcher::src/electron/.github/problem-matchers/eslint-stylish.json"
|
||||
- name: Run Lint
|
||||
shell: bash
|
||||
run: |
|
||||
|
||||
@@ -93,7 +93,6 @@ jobs:
|
||||
shell: bash
|
||||
runs-on: ${{ inputs.build-runs-on }}
|
||||
permissions:
|
||||
artifact-metadata: write
|
||||
attestations: write
|
||||
contents: read
|
||||
id-token: write
|
||||
|
||||
2
.github/workflows/pull-request-labeled.yml
vendored
2
.github/workflows/pull-request-labeled.yml
vendored
@@ -56,7 +56,7 @@ jobs:
|
||||
with:
|
||||
creds: ${{ secrets.ISSUE_TRIAGE_GH_APP_CREDS }}
|
||||
- name: Create comment
|
||||
uses: actions-cool/issues-helper@71b62d7da76e59ff7b193904feb6e77d4dbb2777 # v3.7.6
|
||||
uses: actions-cool/issues-helper@e2ff99831a4f13625d35064e2b3dfe65c07a0396 # v3.7.5
|
||||
with:
|
||||
actions: 'create-comment'
|
||||
token: ${{ steps.generate-token.outputs.token }}
|
||||
|
||||
2
.github/workflows/scorecards.yml
vendored
2
.github/workflows/scorecards.yml
vendored
@@ -51,6 +51,6 @@ jobs:
|
||||
|
||||
# Upload the results to GitHub's code scanning dashboard.
|
||||
- name: "Upload to code-scanning"
|
||||
uses: github/codeql-action/upload-sarif@89a39a4e59826350b863aa6b6252a07ad50cf83e # v3.29.5
|
||||
uses: github/codeql-action/upload-sarif@6bc82e05fd0ea64601dd4b465378bbcf57de0314 # v3.29.5
|
||||
with:
|
||||
sarif_file: results.sarif
|
||||
|
||||
4
.github/workflows/stale.yml
vendored
4
.github/workflows/stale.yml
vendored
@@ -18,7 +18,7 @@ jobs:
|
||||
id: generate-token
|
||||
with:
|
||||
creds: ${{ secrets.ISSUE_TRIAGE_GH_APP_CREDS }}
|
||||
- uses: actions/stale@b5d41d4e1d5dceea10e7104786b73624c18a190f # tag: v10.2.0
|
||||
- uses: actions/stale@997185467fa4f803885201cee163a9f38240193d # tag: v10.1.1
|
||||
with:
|
||||
repo-token: ${{ steps.generate-token.outputs.token }}
|
||||
days-before-stale: 90
|
||||
@@ -42,7 +42,7 @@ jobs:
|
||||
id: generate-token
|
||||
with:
|
||||
creds: ${{ secrets.ISSUE_TRIAGE_GH_APP_CREDS }}
|
||||
- uses: actions/stale@b5d41d4e1d5dceea10e7104786b73624c18a190f # tag: v10.2.0
|
||||
- uses: actions/stale@997185467fa4f803885201cee163a9f38240193d # tag: v10.1.1
|
||||
with:
|
||||
repo-token: ${{ steps.generate-token.outputs.token }}
|
||||
days-before-stale: -1
|
||||
|
||||
2
.github/workflows/update-website-docs.yml
vendored
2
.github/workflows/update-website-docs.yml
vendored
@@ -31,7 +31,7 @@ jobs:
|
||||
echo "isLatestRelease=false" >> $GITHUB_OUTPUT
|
||||
fi
|
||||
- name: Trigger website docs update
|
||||
if: ${{ steps.check-if-latest-release.outputs.isLatestRelease == 'true' }}
|
||||
if: ${{ steps.check-if-latest-release.outputs.isLatestRelease }}
|
||||
env:
|
||||
GH_REPO: electron/website
|
||||
GH_TOKEN: ${{ fromJSON(steps.secret-service.outputs.secrets).WEBSITE_DOCS_UPDATER_APP_TOKEN }}
|
||||
|
||||
3
.github/workflows/windows-publish.yml
vendored
3
.github/workflows/windows-publish.yml
vendored
@@ -54,7 +54,6 @@ jobs:
|
||||
publish-x64-win:
|
||||
uses: ./.github/workflows/pipeline-segment-electron-publish.yml
|
||||
permissions:
|
||||
artifact-metadata: write
|
||||
attestations: write
|
||||
contents: read
|
||||
id-token: write
|
||||
@@ -73,7 +72,6 @@ jobs:
|
||||
publish-arm64-win:
|
||||
uses: ./.github/workflows/pipeline-segment-electron-publish.yml
|
||||
permissions:
|
||||
artifact-metadata: write
|
||||
attestations: write
|
||||
contents: read
|
||||
id-token: write
|
||||
@@ -92,7 +90,6 @@ jobs:
|
||||
publish-x86-win:
|
||||
uses: ./.github/workflows/pipeline-segment-electron-publish.yml
|
||||
permissions:
|
||||
artifact-metadata: write
|
||||
attestations: write
|
||||
contents: read
|
||||
id-token: write
|
||||
|
||||
@@ -1 +1,2 @@
|
||||
npm run check-signed-commits
|
||||
npm run prepack
|
||||
|
||||
5
BUILD.gn
5
BUILD.gn
@@ -596,7 +596,6 @@ source_set("electron_lib") {
|
||||
use_libcxx_modules = false
|
||||
|
||||
deps += [
|
||||
"//components/os_crypt/async/browser:keychain_key_provider",
|
||||
"//components/os_crypt/common:keychain_password_mac",
|
||||
"//components/remote_cocoa/app_shim",
|
||||
"//components/remote_cocoa/browser",
|
||||
@@ -659,9 +658,6 @@ source_set("electron_lib") {
|
||||
":libnotify_loader",
|
||||
"//build/config/linux/gtk",
|
||||
"//components/crash/content/browser",
|
||||
"//components/os_crypt/async/browser:freedesktop_secret_key_provider",
|
||||
"//components/os_crypt/async/browser:posix_key_provider",
|
||||
"//components/os_crypt/async/browser:secret_portal_key_provider",
|
||||
"//dbus",
|
||||
"//device/bluetooth",
|
||||
"//third_party/crashpad/crashpad/client",
|
||||
@@ -702,7 +698,6 @@ source_set("electron_lib") {
|
||||
deps += [
|
||||
"//components/app_launch_prefetch",
|
||||
"//components/crash/core/app:crash_export_thunks",
|
||||
"//components/os_crypt/async/browser:dpapi_key_provider",
|
||||
"//third_party/libxml:xml_writer",
|
||||
"//ui/wm",
|
||||
"//ui/wm/public",
|
||||
|
||||
@@ -155,10 +155,6 @@ e test # Run full test suite
|
||||
|
||||
When working on the `roller/chromium/main` branch to upgrade Chromium activate the "Electron Chromium Upgrade" skill.
|
||||
|
||||
## Pull Requests
|
||||
|
||||
PR bodies must always include a `Notes:` section as the **last line** of the body. This is a consumer-facing release note for Electron app developers — describe the user-visible fix or change, not internal implementation details. Use `Notes: none` if there is no user-facing change.
|
||||
|
||||
## Code Style
|
||||
|
||||
**C++:** Follows Chromium style, enforced by clang-format
|
||||
|
||||
4
DEPS
4
DEPS
@@ -2,9 +2,9 @@ gclient_gn_args_from = 'src'
|
||||
|
||||
vars = {
|
||||
'chromium_version':
|
||||
'147.0.7699.0',
|
||||
'146.0.7650.0',
|
||||
'node_version':
|
||||
'v24.14.0',
|
||||
'v24.13.0',
|
||||
'nan_version':
|
||||
'675cefebca42410733da8a454c8d9391fcebfbc2',
|
||||
'squirrel.mac_version':
|
||||
|
||||
@@ -9,6 +9,5 @@
|
||||
"embedded_asar_integrity_validation": "0",
|
||||
"only_load_app_from_asar": "0",
|
||||
"load_browser_process_specific_v8_snapshot": "0",
|
||||
"grant_file_protocol_extra_privileges": "1",
|
||||
"wasm_trap_handlers": "1"
|
||||
"grant_file_protocol_extra_privileges": "1"
|
||||
}
|
||||
|
||||
21
build/siso/backend.star
Normal file
21
build/siso/backend.star
Normal file
@@ -0,0 +1,21 @@
|
||||
# -*- bazel-starlark -*-
|
||||
|
||||
load("@builtin//struct.star", "module")
|
||||
|
||||
def __platform_properties(ctx):
|
||||
container_image = "docker://gcr.io/chops-public-images-prod/rbe/siso-chromium/linux@sha256:d7cb1ab14a0f20aa669c23f22c15a9dead761dcac19f43985bf9dd5f41fbef3a"
|
||||
return {
|
||||
"default": {
|
||||
"OSFamily": "Linux",
|
||||
"container-image": container_image,
|
||||
},
|
||||
"large": {
|
||||
"OSFamily": "Linux",
|
||||
"container-image": container_image,
|
||||
},
|
||||
}
|
||||
|
||||
backend = module(
|
||||
"backend",
|
||||
platform_properties = __platform_properties,
|
||||
)
|
||||
66
build/siso/main.star
Normal file
66
build/siso/main.star
Normal file
@@ -0,0 +1,66 @@
|
||||
load("@builtin//encoding.star", "json")
|
||||
load("@builtin//path.star", "path")
|
||||
load("@builtin//runtime.star", "runtime")
|
||||
load("@builtin//struct.star", "module")
|
||||
load("@config//main.star", upstream_init = "init")
|
||||
load("@config//win_sdk.star", "win_sdk")
|
||||
load("@config//gn_logs.star", "gn_logs")
|
||||
|
||||
def init(ctx):
|
||||
mod = upstream_init(ctx)
|
||||
step_config = json.decode(mod.step_config)
|
||||
|
||||
# Buildbarn doesn't support input_root_absolute_path so disable that
|
||||
for rule in step_config["rules"]:
|
||||
input_root_absolute_path = rule.get("input_root_absolute_path", False)
|
||||
if input_root_absolute_path:
|
||||
rule.pop("input_root_absolute_path", None)
|
||||
|
||||
# Only wrap clang rules with a remote wrapper if not on Linux. These are currently only
|
||||
# needed for X-Compile builds, which run on Windows and Mac.
|
||||
if runtime.os != "linux":
|
||||
for rule in step_config["rules"]:
|
||||
if rule["name"].startswith("clang/") or rule["name"].startswith("clang-cl/"):
|
||||
rule["remote_wrapper"] = "../../buildtools/reclient_cfgs/chromium-browser-clang/clang_remote_wrapper"
|
||||
if "inputs" not in rule:
|
||||
rule["inputs"] = []
|
||||
rule["inputs"].append("buildtools/reclient_cfgs/chromium-browser-clang/clang_remote_wrapper")
|
||||
rule["inputs"].append("third_party/llvm-build/Release+Asserts_linux/bin/clang")
|
||||
|
||||
if "executables" not in step_config:
|
||||
step_config["executables"] = []
|
||||
step_config["executables"].append("buildtools/reclient_cfgs/chromium-browser-clang/clang_remote_wrapper")
|
||||
step_config["executables"].append("third_party/llvm-build/Release+Asserts_linux/bin/clang")
|
||||
|
||||
if runtime.os == "darwin":
|
||||
# Update platforms to match our default siso config instead of reclient configs.
|
||||
step_config["platforms"].update({
|
||||
"clang": step_config["platforms"]["default"],
|
||||
"clang_large": step_config["platforms"]["default"],
|
||||
})
|
||||
|
||||
if runtime.os == "windows":
|
||||
# Add additional Windows SDK headers needed by Electron
|
||||
win_toolchain_dir = win_sdk.toolchain_dir(ctx)
|
||||
if win_toolchain_dir:
|
||||
sdk_version = gn_logs.read(ctx).get("windows_sdk_version")
|
||||
step_config["input_deps"][win_toolchain_dir + ":headers"].extend([
|
||||
# third_party/electron_node/deps/uv/include/uv/win.h includes mswsock.h
|
||||
path.join(win_toolchain_dir, "Windows Kits/10/Include", sdk_version, "um/mswsock.h"),
|
||||
# third_party/electron_node/src/debug_utils.cc includes lm.h
|
||||
path.join(win_toolchain_dir, "Windows Kits/10/Include", sdk_version, "um/Lm.h"),
|
||||
])
|
||||
|
||||
# Update platforms to match our default siso config instead of reclient configs.
|
||||
step_config["platforms"].update({
|
||||
"clang-cl": step_config["platforms"]["default"],
|
||||
"clang-cl_large": step_config["platforms"]["default"],
|
||||
"lld-link": step_config["platforms"]["default"],
|
||||
})
|
||||
|
||||
return module(
|
||||
"config",
|
||||
step_config = json.encode(step_config),
|
||||
filegroups = mod.filegroups,
|
||||
handlers = mod.handlers,
|
||||
)
|
||||
@@ -250,9 +250,7 @@ Returns:
|
||||
|
||||
Emitted when the user clicks the native macOS new tab button. The new
|
||||
tab button is only visible if the current `BrowserWindow` has a
|
||||
`tabbingIdentifier`.
|
||||
|
||||
You must create a window in this handler in order for macOS tabbing to work as expected.
|
||||
`tabbingIdentifier`
|
||||
|
||||
### Event: 'browser-window-blur'
|
||||
|
||||
@@ -635,7 +633,7 @@ Returns `string` - The current application directory.
|
||||
Returns `string` - A path to a special directory or file associated with `name`. On
|
||||
failure, an `Error` is thrown.
|
||||
|
||||
If `app.getPath('logs')` is called without calling `app.setAppLogsPath()` being called first, a default log directory will be created equivalent to calling `app.setAppLogsPath()` without a `path` parameter.
|
||||
If `app.getPath('logs')` is called without called `app.setAppLogsPath()` being called first, a default log directory will be created equivalent to calling `app.setAppLogsPath()` without a `path` parameter.
|
||||
|
||||
### `app.getFileIcon(path[, options])`
|
||||
|
||||
@@ -650,7 +648,7 @@ Returns `Promise<NativeImage>` - fulfilled with the app's icon, which is a [Nati
|
||||
|
||||
Fetches a path's associated icon.
|
||||
|
||||
On _Windows_, there are 2 kinds of icons:
|
||||
On _Windows_, there a 2 kinds of icons:
|
||||
|
||||
* Icons associated with certain file extensions, like `.mp3`, `.png`, etc.
|
||||
* Icons inside the file itself, like `.exe`, `.dll`, `.ico`.
|
||||
@@ -766,7 +764,7 @@ app.getPreferredSystemLanguages() // ['fr-CA', 'en-US', 'zh-Hans-FI', 'es-419']
|
||||
|
||||
Both the available languages and regions and the possible return values differ between the two operating systems.
|
||||
|
||||
As can be seen with the example above, on Windows, it is possible that a preferred system language has no country code, and that one of the preferred system languages corresponds with the language used for the regional format. On macOS, the region serves more as a default country code: the user doesn't need to have Finnish as a preferred language to use Finland as the region, and the country code `FI` is used as the country code for preferred system languages that do not have associated countries in the language name.
|
||||
As can be seen with the example above, on Windows, it is possible that a preferred system language has no country code, and that one of the preferred system languages corresponds with the language used for the regional format. On macOS, the region serves more as a default country code: the user doesn't need to have Finnish as a preferred language to use Finland as the region,and the country code `FI` is used as the country code for preferred system languages that do not have associated countries in the language name.
|
||||
|
||||
### `app.addRecentDocument(path)` _macOS_ _Windows_
|
||||
|
||||
@@ -1124,19 +1122,6 @@ Updates the current activity if its type matches `type`, merging the entries fro
|
||||
|
||||
Changes the [Application User Model ID][app-user-model-id] to `id`.
|
||||
|
||||
### `app.setToastActivatorCLSID(id)` _Windows_
|
||||
|
||||
* `id` string
|
||||
|
||||
Changes the [Toast Activator CLSID][toast-activator-clsid] to `id`. If one is not set via this method, it will be randomly generated for the app.
|
||||
|
||||
* The value must be a valid GUID/CLSID in one of the following forms:
|
||||
* Canonical brace-wrapped: `{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}` (preferred)
|
||||
* Canonical without braces: `XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX` (braces will be added automatically)
|
||||
* Hex digits are case-insensitive.
|
||||
|
||||
This method should be called early (before showing notifications) so the value is baked into the registration/shortcut. Supplying an empty string or an unparsable value throws and leaves the existing (or generated) CLSID unchanged. If this method is never called, a random CLSID is generated once per run and exposed via `app.toastActivatorCLSID`.
|
||||
|
||||
### `app.setActivationPolicy(policy)` _macOS_
|
||||
|
||||
* `policy` string - Can be 'regular', 'accessory', or 'prohibited'.
|
||||
@@ -1241,7 +1226,7 @@ Returns `boolean` - whether hardware acceleration is currently enabled.
|
||||
### `app.disableDomainBlockingFor3DAPIs()`
|
||||
|
||||
By default, Chromium disables 3D APIs (e.g. WebGL) until restart on a per
|
||||
domain basis if the GPU process crashes too frequently. This function
|
||||
domain basis if the GPU processes crashes too frequently. This function
|
||||
disables that behavior.
|
||||
|
||||
This method can only be called before app is ready.
|
||||
@@ -1332,7 +1317,7 @@ Returns `boolean` - Whether the current desktop environment is Unity launcher.
|
||||
### `app.getLoginItemSettings([options])` _macOS_ _Windows_
|
||||
|
||||
* `options` Object (optional)
|
||||
* `type` string (optional) _macOS_ - Can be `mainAppService`, `agentService`, `daemonService`, or `loginItemService`. Defaults to `mainAppService`. Only available on macOS 13 and up. See [app.setLoginItemSettings](app.md#appsetloginitemsettingssettings-macos-windows) for more information about each type.
|
||||
* `type` string (optional) _macOS_ - Can be one of `mainAppService`, `agentService`, `daemonService`, or `loginItemService`. Defaults to `mainAppService`. Only available on macOS 13 and up. See [app.setLoginItemSettings](app.md#appsetloginitemsettingssettings-macos-windows) for more information about each type.
|
||||
* `serviceName` string (optional) _macOS_ - The name of the service. Required if `type` is non-default. Only available on macOS 13 and up.
|
||||
* `path` string (optional) _Windows_ - The executable path to compare against. Defaults to `process.execPath`.
|
||||
* `args` string[] (optional) _Windows_ - The command-line arguments to compare against. Defaults to an empty array.
|
||||
@@ -1347,13 +1332,13 @@ Returns `Object`:
|
||||
* `wasOpenedAtLogin` boolean _macOS_ - `true` if the app was opened at login automatically.
|
||||
* `wasOpenedAsHidden` boolean _macOS_ _Deprecated_ - `true` if the app was opened as a hidden login item. This indicates that the app should not open any windows at startup. This setting is not available on [MAS builds][mas-builds] or on macOS 13 and up.
|
||||
* `restoreState` boolean _macOS_ _Deprecated_ - `true` if the app was opened as a login item that should restore the state from the previous session. This indicates that the app should restore the windows that were open the last time the app was closed. This setting is not available on [MAS builds][mas-builds] or on macOS 13 and up.
|
||||
* `status` string _macOS_ - can be `not-registered`, `enabled`, `requires-approval`, or `not-found`.
|
||||
* `status` string _macOS_ - can be one of `not-registered`, `enabled`, `requires-approval`, or `not-found`.
|
||||
* `executableWillLaunchAtLogin` boolean _Windows_ - `true` if app is set to open at login and its run key is not deactivated. This differs from `openAtLogin` as it ignores the `args` option, this property will be true if the given executable would be launched at login with **any** arguments.
|
||||
* `launchItems` Object[] _Windows_
|
||||
* `name` string _Windows_ - name value of a registry entry.
|
||||
* `path` string _Windows_ - The executable to an app that corresponds to a registry entry.
|
||||
* `args` string[] _Windows_ - the command-line arguments to pass to the executable.
|
||||
* `scope` string _Windows_ - can be `user` or `machine`. Indicates whether the registry entry is under `HKEY_CURRENT USER` or `HKEY_LOCAL_MACHINE`.
|
||||
* `scope` string _Windows_ - one of `user` or `machine`. Indicates whether the registry entry is under `HKEY_CURRENT USER` or `HKEY_LOCAL_MACHINE`.
|
||||
* `enabled` boolean _Windows_ - `true` if the app registry key is startup approved and therefore shows as `enabled` in Task Manager and Windows settings.
|
||||
|
||||
### `app.setLoginItemSettings(settings)` _macOS_ _Windows_
|
||||
@@ -1719,13 +1704,8 @@ platforms) that allows you to perform actions on your app icon in the user's doc
|
||||
|
||||
A `boolean` property that returns `true` if the app is packaged, `false` otherwise. For many apps, this property can be used to distinguish development and production environments.
|
||||
|
||||
### `app.toastActivatorCLSID` _Windows_ _Readonly_
|
||||
|
||||
A `string` property that returns the app's [Toast Activator CLSID][toast-activator-clsid].
|
||||
|
||||
[tasks]:https://learn.microsoft.com/en-us/windows/win32/shell/taskbar-extensions#tasks
|
||||
[app-user-model-id]: https://learn.microsoft.com/en-us/windows/win32/shell/appids
|
||||
[toast-activator-clsid]: https://learn.microsoft.com/en-us/windows/win32/properties/props-system-appusermodel-toastactivatorclsid
|
||||
[electron-forge]: https://www.electronforge.io/
|
||||
[electron-packager]: https://github.com/electron/packager
|
||||
[CFBundleURLTypes]: https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/TP40009249-102207-TPXREF115
|
||||
|
||||
@@ -351,11 +351,7 @@ Emitted when the window has closed a sheet.
|
||||
|
||||
#### Event: 'new-window-for-tab' _macOS_
|
||||
|
||||
Emitted when the user clicks the native macOS new tab button. The new
|
||||
tab button is only visible if the current `BrowserWindow` has a
|
||||
`tabbingIdentifier`.
|
||||
|
||||
You must create a window in this handler in order for macOS tabbing to work as expected.
|
||||
Emitted when the native new tab button is clicked.
|
||||
|
||||
#### Event: 'system-context-menu' _Windows_ _Linux_
|
||||
|
||||
@@ -1053,7 +1049,7 @@ under this mode apps can choose to optimize their UI for tablets, such as
|
||||
enlarging the titlebar and hiding titlebar buttons.
|
||||
|
||||
This API returns whether the window is in tablet mode, and the `resize` event
|
||||
can be used to listen to changes to tablet mode.
|
||||
can be be used to listen to changes to tablet mode.
|
||||
|
||||
#### `win.getMediaSourceId()`
|
||||
|
||||
|
||||
@@ -435,11 +435,7 @@ Emitted when the window has closed a sheet.
|
||||
|
||||
#### Event: 'new-window-for-tab' _macOS_
|
||||
|
||||
Emitted when the user clicks the native macOS new tab button. The new
|
||||
tab button is only visible if the current `BrowserWindow` has a
|
||||
`tabbingIdentifier`.
|
||||
|
||||
You must create a window in this handler in order for macOS tabbing to work as expected.
|
||||
Emitted when the native new tab button is clicked.
|
||||
|
||||
#### Event: 'system-context-menu' _Windows_ _Linux_
|
||||
|
||||
@@ -1169,7 +1165,7 @@ under this mode apps can choose to optimize their UI for tablets, such as
|
||||
enlarging the titlebar and hiding titlebar buttons.
|
||||
|
||||
This API returns whether the window is in tablet mode, and the `resize` event
|
||||
can be used to listen to changes to tablet mode.
|
||||
can be be used to listen to changes to tablet mode.
|
||||
|
||||
#### `win.getMediaSourceId()`
|
||||
|
||||
|
||||
@@ -264,7 +264,7 @@ will not be allowed. The `finish` event is emitted just after the end operation.
|
||||
Cancels an ongoing HTTP transaction. If the request has already emitted the
|
||||
`close` event, the abort operation will have no effect. Otherwise an ongoing
|
||||
event will emit `abort` and `close` events. Additionally, if there is an ongoing
|
||||
response object, it will emit the `aborted` event.
|
||||
response object,it will emit the `aborted` event.
|
||||
|
||||
#### `request.followRedirect()`
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
Process: [Main](../glossary.md#main-process), [Renderer](../glossary.md#renderer-process) _Deprecated_ (non-sandboxed only)
|
||||
|
||||
> [!NOTE]
|
||||
> Using the `clipboard` API from the renderer process is deprecated.
|
||||
> Using the `clipoard` API from the renderer process is deprecated.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> If you want to call this API from a renderer process,
|
||||
|
||||
@@ -172,7 +172,7 @@ Enables net log events to be saved and writes them to `path`.
|
||||
Sets the verbosity of logging when used together with `--enable-logging`.
|
||||
`N` should be one of [Chrome's LogSeverities][severities].
|
||||
|
||||
Note that two complementary logging mechanisms in Chromium -- `LOG()`
|
||||
Note that two complimentary logging mechanisms in Chromium -- `LOG()`
|
||||
and `VLOG()` -- are controlled by different switches. `--log-level`
|
||||
controls `LOG()` messages, while `--v` and `--vmodule` control `VLOG()`
|
||||
messages. So you may want to use a combination of these three switches
|
||||
@@ -354,11 +354,6 @@ Affects the default output directory of [v8.setHeapSnapshotNearHeapLimit](https:
|
||||
|
||||
Disable exposition of [Navigator API][] on the global scope from Node.js.
|
||||
|
||||
### `--experimental-transform-types`
|
||||
|
||||
Enables the [transformation](https://nodejs.org/api/typescript.html#type-stripping)
|
||||
of TypeScript-only syntax into JavaScript code.
|
||||
|
||||
## Chromium Flags
|
||||
|
||||
There isn't a documented list of all Chromium switches, but there are a few ways to find them.
|
||||
@@ -375,13 +370,6 @@ Keep in mind that standalone switches can sometimes be split into individual fea
|
||||
|
||||
Finally, you'll need to ensure that the version of Chromium in Electron matches the version of the browser you're using to cross-reference the switches.
|
||||
|
||||
### Chromium features relevant to Electron apps
|
||||
|
||||
* `AlwaysLogLOAFURL`: enables script attribution for
|
||||
[`long-animation-frame`](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Long_animation_frame_timing)
|
||||
`PerformanceObserver` events for non-http(s), non-data, non-blob URLs (such as `file:` or custom
|
||||
protocol URLs).
|
||||
|
||||
[app]: app.md
|
||||
[append-switch]: command-line.md#commandlineappendswitchswitch-value
|
||||
[debugging-main-process]: ../tutorial/debugging-main-process.md
|
||||
|
||||
@@ -107,7 +107,7 @@ the response.
|
||||
cookie and will not be retained between sessions.
|
||||
* `sameSite` string (optional) - The [Same Site](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_cookies) policy to apply to this cookie. Can be `unspecified`, `no_restriction`, `lax` or `strict`. Default is `lax`.
|
||||
|
||||
Returns `Promise<void>` - A promise which resolves when the cookie has been set.
|
||||
Returns `Promise<void>` - A promise which resolves when the cookie has been set
|
||||
|
||||
Sets a cookie with `details`.
|
||||
|
||||
@@ -116,16 +116,16 @@ Sets a cookie with `details`.
|
||||
* `url` string - The URL associated with the cookie.
|
||||
* `name` string - The name of cookie to remove.
|
||||
|
||||
Returns `Promise<void>` - A promise which resolves when the cookie has been removed.
|
||||
Returns `Promise<void>` - A promise which resolves when the cookie has been removed
|
||||
|
||||
Removes the cookies matching `url` and `name`.
|
||||
Removes the cookies matching `url` and `name`
|
||||
|
||||
#### `cookies.flushStore()`
|
||||
|
||||
Returns `Promise<void>` - A promise which resolves when the cookie store has been flushed.
|
||||
Returns `Promise<void>` - A promise which resolves when the cookie store has been flushed
|
||||
|
||||
Writes any unwritten cookies data to disk.
|
||||
Writes any unwritten cookies data to disk
|
||||
|
||||
Cookies written by any method will not be written to disk immediately, but will be written every 30 seconds or 512 operations.
|
||||
Cookies written by any method will not be written to disk immediately, but will be written every 30 seconds or 512 operations
|
||||
|
||||
Calling this method can cause the cookie to be written to disk immediately.
|
||||
|
||||
@@ -49,7 +49,7 @@ Use the `system-ui` keyword to match the smoothness to the OS design language.
|
||||
| Value: | `60%` | `0%` |
|
||||
| Example: |  |  |
|
||||
|
||||
### Controlling availability
|
||||
### Controlling availibility
|
||||
|
||||
This CSS rule can be disabled using the Blink feature flag `ElectronCSSCornerSmoothing`.
|
||||
|
||||
|
||||
@@ -94,45 +94,18 @@ The `desktopCapturer` module has the following methods:
|
||||
Returns `Promise<DesktopCapturerSource[]>` - Resolves with an array of [`DesktopCapturerSource`](structures/desktop-capturer-source.md) objects, each `DesktopCapturerSource` represents a screen or an individual window that can be captured.
|
||||
|
||||
> [!NOTE]
|
||||
|
||||
> * Capturing audio requires `NSAudioCaptureUsageDescription` Info.plist key on macOS 14.2 Sonoma and higher - [read more](#macos-versions-142-or-higher).
|
||||
> * Capturing the screen contents requires user consent on macOS 10.15 Catalina or higher, which can detected by [`systemPreferences.getMediaAccessStatus`][].
|
||||
> Capturing the screen contents requires user consent on macOS 10.15 Catalina or higher,
|
||||
> which can detected by [`systemPreferences.getMediaAccessStatus`][].
|
||||
|
||||
[`navigator.mediaDevices.getUserMedia`]: https://developer.mozilla.org/en/docs/Web/API/MediaDevices/getUserMedia
|
||||
[`systemPreferences.getMediaAccessStatus`]: system-preferences.md#systempreferencesgetmediaaccessstatusmediatype-windows-macos
|
||||
|
||||
## Caveats
|
||||
|
||||
### Linux
|
||||
|
||||
`desktopCapturer.getSources(options)` only returns a single source on Linux when using Pipewire.
|
||||
|
||||
PipeWire supports a single capture for both screens and windows. If you request the window and screen type, the selected source will be returned as a window capture.
|
||||
|
||||
---
|
||||
`navigator.mediaDevices.getUserMedia` does not work on macOS for audio capture due to a fundamental limitation whereby apps that want to access the system's audio require a [signed kernel extension](https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/KernelExtensions/KernelExtensions.html). Chromium, and by extension Electron, does not provide this.
|
||||
|
||||
### MacOS versions 14.2 or higher
|
||||
|
||||
`NSAudioCaptureUsageDescription` Info.plist key must be added in-order for audio to be captured by `desktopCapturer`. If instead you are running electron from another program like a terminal or IDE then that parent program must contain the Info.plist key.
|
||||
|
||||
This is in order to facillitate use of Apple's new [CoreAudio Tap API](https://developer.apple.com/documentation/CoreAudio/capturing-system-audio-with-core-audio-taps#Configure-the-sample-code-project) by Chromium.
|
||||
|
||||
> [!WARNING]
|
||||
> Failure of `desktopCapturer` to start an audio stream due to `NSAudioCaptureUsageDescription` permission not present will still create a dead audio stream however no warnings or errors are displayed.
|
||||
|
||||
As of electron `v39.0.0-beta.4` Chromium [made Apple's new `CoreAudio Tap API` the default](https://source.chromium.org/chromium/chromium/src/+/ad17e8f8b93d5f34891b06085d373a668918255e) for desktop audio capture. There is no fallback to the older `Screen & System Audio Recording` permissions system even if [CoreAudio Tap API](https://developer.apple.com/documentation/CoreAudio/capturing-system-audio-with-core-audio-taps) stream creation fails.
|
||||
|
||||
If you need to continue using `Screen & System Audio Recording` permissions for `desktopCapturer` on macOS versions 14.2 and later, you can apply a chromium feature flag to force use of that older permissions system:
|
||||
|
||||
```js
|
||||
// main.js (right beneath your require/import statments)
|
||||
app.commandLine.appendSwitch('disable-features', 'MacCatapLoopbackAudioForScreenShare')
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### MacOS versions 12.7.6 or lower
|
||||
|
||||
`navigator.mediaDevices.getUserMedia` does not work on macOS versions 12.7.6 and prior for audio capture due to a fundamental limitation whereby apps that want to access the system's audio require a [signed kernel extension](https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/KernelExtensions/KernelExtensions.html). Chromium, and by extension Electron, does not provide this. Only in macOS 13 and onwards does Apple provide APIs to capture desktop audio without the need for a signed kernel extension.
|
||||
|
||||
It is possible to circumvent this limitation by capturing system audio with another macOS app like [BlackHole](https://existential.audio/blackhole/) or [Soundflower](https://rogueamoeba.com/freebies/soundflower/) and passing it through a virtual audio input device. This virtual device can then be queried with `navigator.mediaDevices.getUserMedia`.
|
||||
It is possible to circumvent this limitation by capturing system audio with another macOS app like Soundflower and passing it through a virtual audio input device. This virtual device can then be queried with `navigator.mediaDevices.getUserMedia`.
|
||||
|
||||
@@ -344,7 +344,7 @@ Displays a modal dialog that shows an error message.
|
||||
|
||||
This API can be called safely before the `ready` event the `app` module emits,
|
||||
it is usually used to report errors in early stage of startup. If called
|
||||
before the app `ready` event on Linux, the message will be emitted to stderr,
|
||||
before the app `ready`event on Linux, the message will be emitted to stderr,
|
||||
and no GUI dialog will appear.
|
||||
|
||||
### `dialog.showCertificateTrustDialog([window, ]options)` _macOS_ _Windows_
|
||||
|
||||
@@ -34,7 +34,7 @@ Returns:
|
||||
* `error` Error - Typically holds an error string identifying failure root cause.
|
||||
|
||||
Emitted when an error was encountered while streaming response data events. For
|
||||
instance, if the server closes the underlying connection while the response is still
|
||||
instance, if the server closes the underlying while the response is still
|
||||
streaming, an `error` event will be emitted on the response object and a `close`
|
||||
event will subsequently follow on the request object.
|
||||
|
||||
|
||||
@@ -39,7 +39,7 @@ indicate which letter should get a generated accelerator. For example, using
|
||||
opens the associated menu. The indicated character in the button label then gets an
|
||||
underline, and the `&` character is not displayed on the button label.
|
||||
|
||||
In order to escape the `&` character in an item name, add a preceding `&`. For example, `&&File` would result in `&File` displayed on the button label.
|
||||
In order to escape the `&` character in an item name, add a proceeding `&`. For example, `&&File` would result in `&File` displayed on the button label.
|
||||
|
||||
Passing `null` will suppress the default menu. On Windows and Linux,
|
||||
this has the additional effect of removing the menu bar from the window.
|
||||
@@ -123,7 +123,7 @@ Appends the `menuItem` to the menu.
|
||||
|
||||
- `id` string
|
||||
|
||||
Returns [`MenuItem | null`](menu-item.md) - the item with the specified `id`
|
||||
Returns `MenuItem | null` the item with the specified `id`
|
||||
|
||||
#### `menu.insert(pos, menuItem)`
|
||||
|
||||
|
||||
@@ -83,4 +83,4 @@ Currently, Windows high contrast is the only system setting that triggers forced
|
||||
|
||||
### `nativeTheme.prefersReducedTransparency` _Readonly_
|
||||
|
||||
A `boolean` that indicates whether the user has chosen via system accessibility settings to reduce transparency at the OS level.
|
||||
A `boolean` that indicates the whether the user has chosen via system accessibility settings to reduce transparency at the OS level.
|
||||
|
||||
@@ -67,22 +67,6 @@ Emitted when the notification is shown to the user. Note that this event can be
|
||||
multiple times as a notification can be shown multiple times through the
|
||||
`show()` method.
|
||||
|
||||
```js
|
||||
const { Notification, app } = require('electron')
|
||||
|
||||
app.whenReady().then(() => {
|
||||
const n = new Notification({
|
||||
title: 'Title!',
|
||||
subtitle: 'Subtitle!',
|
||||
body: 'Body!'
|
||||
})
|
||||
|
||||
n.on('show', () => console.log('Notification shown!'))
|
||||
|
||||
n.show()
|
||||
})
|
||||
```
|
||||
|
||||
#### Event: 'click'
|
||||
|
||||
Returns:
|
||||
@@ -91,22 +75,6 @@ Returns:
|
||||
|
||||
Emitted when the notification is clicked by the user.
|
||||
|
||||
```js
|
||||
const { Notification, app } = require('electron')
|
||||
|
||||
app.whenReady().then(() => {
|
||||
const n = new Notification({
|
||||
title: 'Title!',
|
||||
subtitle: 'Subtitle!',
|
||||
body: 'Body!'
|
||||
})
|
||||
|
||||
n.on('click', () => console.log('Notification clicked!'))
|
||||
|
||||
n.show()
|
||||
})
|
||||
```
|
||||
|
||||
#### Event: 'close'
|
||||
|
||||
Returns:
|
||||
@@ -120,85 +88,21 @@ is closed.
|
||||
|
||||
On Windows, the `close` event can be emitted in one of three ways: programmatic dismissal with `notification.close()`, by the user closing the notification, or via system timeout. If a notification is in the Action Center after the initial `close` event is emitted, a call to `notification.close()` will remove the notification from the action center but the `close` event will not be emitted again.
|
||||
|
||||
```js
|
||||
const { Notification, app } = require('electron')
|
||||
|
||||
app.whenReady().then(() => {
|
||||
const n = new Notification({
|
||||
title: 'Title!',
|
||||
subtitle: 'Subtitle!',
|
||||
body: 'Body!'
|
||||
})
|
||||
|
||||
n.on('close', () => console.log('Notification closed!'))
|
||||
|
||||
n.show()
|
||||
})
|
||||
```
|
||||
|
||||
#### Event: 'reply' _macOS_ _Windows_
|
||||
#### Event: 'reply' _macOS_
|
||||
|
||||
Returns:
|
||||
|
||||
* `details` Event\<\>
|
||||
* `reply` string - The string the user entered into the inline reply field.
|
||||
* `reply` string _Deprecated_
|
||||
* `event` Event
|
||||
* `reply` string - The string the user entered into the inline reply field.
|
||||
|
||||
Emitted when the user clicks the "Reply" button on a notification with `hasReply: true`.
|
||||
|
||||
```js
|
||||
const { Notification, app } = require('electron')
|
||||
|
||||
app.whenReady().then(() => {
|
||||
const n = new Notification({
|
||||
title: 'Send a Message',
|
||||
body: 'Body Text',
|
||||
hasReply: true,
|
||||
replyPlaceholder: 'Message text...'
|
||||
})
|
||||
|
||||
n.on('reply', (e, reply) => console.log(`User replied: ${reply}`))
|
||||
n.on('click', () => console.log('Notification clicked'))
|
||||
|
||||
n.show()
|
||||
})
|
||||
```
|
||||
|
||||
#### Event: 'action' _macOS_ _Windows_
|
||||
#### Event: 'action' _macOS_
|
||||
|
||||
Returns:
|
||||
|
||||
* `details` Event\<\>
|
||||
* `actionIndex` number - The index of the action that was activated.
|
||||
* `selectionIndex` number _Windows_ - The index of the selected item, if one was chosen. -1 if none was chosen.
|
||||
* `actionIndex` number _Deprecated_
|
||||
* `selectionIndex` number _Windows_ _Deprecated_
|
||||
|
||||
```js
|
||||
const { Notification, app } = require('electron')
|
||||
|
||||
app.whenReady().then(() => {
|
||||
const items = ['One', 'Two', 'Three']
|
||||
const n = new Notification({
|
||||
title: 'Choose an Action!',
|
||||
actions: [
|
||||
{ type: 'button', text: 'Action 1' },
|
||||
{ type: 'button', text: 'Action 2' },
|
||||
{ type: 'selection', text: 'Apply', items }
|
||||
]
|
||||
})
|
||||
|
||||
n.on('click', () => console.log('Notification clicked'))
|
||||
n.on('action', (e) => {
|
||||
console.log(`User triggered action at index: ${e.actionIndex}`)
|
||||
if (e.selectionIndex > -1) {
|
||||
console.log(`User chose selection item '${items[e.selectionIndex]}'`)
|
||||
}
|
||||
})
|
||||
|
||||
n.show()
|
||||
})
|
||||
```
|
||||
* `event` Event
|
||||
* `index` number - The index of the action that was activated.
|
||||
|
||||
#### Event: 'failed' _Windows_
|
||||
|
||||
@@ -209,22 +113,6 @@ Returns:
|
||||
|
||||
Emitted when an error is encountered while creating and showing the native notification.
|
||||
|
||||
```js
|
||||
const { Notification, app } = require('electron')
|
||||
|
||||
app.whenReady().then(() => {
|
||||
const n = new Notification({
|
||||
title: 'Bad Action'
|
||||
})
|
||||
|
||||
n.on('failed', (e, err) => {
|
||||
console.log('Notification failed: ', err)
|
||||
})
|
||||
|
||||
n.show()
|
||||
})
|
||||
```
|
||||
|
||||
### Instance Methods
|
||||
|
||||
Objects created with the `new Notification()` constructor have the following instance methods:
|
||||
@@ -238,42 +126,12 @@ call this method before the OS will display it.
|
||||
If the notification has been shown before, this method will dismiss the previously
|
||||
shown notification and create a new one with identical properties.
|
||||
|
||||
```js
|
||||
const { Notification, app } = require('electron')
|
||||
|
||||
app.whenReady().then(() => {
|
||||
const n = new Notification({
|
||||
title: 'Title!',
|
||||
subtitle: 'Subtitle!',
|
||||
body: 'Body!'
|
||||
})
|
||||
|
||||
n.show()
|
||||
})
|
||||
```
|
||||
|
||||
#### `notification.close()`
|
||||
|
||||
Dismisses the notification.
|
||||
|
||||
On Windows, calling `notification.close()` while the notification is visible on screen will dismiss the notification and remove it from the Action Center. If `notification.close()` is called after the notification is no longer visible on screen, calling `notification.close()` will try remove it from the Action Center.
|
||||
|
||||
```js
|
||||
const { Notification, app } = require('electron')
|
||||
|
||||
app.whenReady().then(() => {
|
||||
const n = new Notification({
|
||||
title: 'Title!',
|
||||
subtitle: 'Subtitle!',
|
||||
body: 'Body!'
|
||||
})
|
||||
|
||||
n.show()
|
||||
|
||||
setTimeout(() => n.close(), 5000)
|
||||
})
|
||||
```
|
||||
|
||||
### Instance Properties
|
||||
|
||||
#### `notification.title`
|
||||
|
||||
@@ -99,13 +99,13 @@ property is used instead of the `--throw-deprecation` command line flag.
|
||||
|
||||
A `boolean` that controls whether or not deprecations printed to `stderr` include
|
||||
their stack trace. Setting this to `true` will print stack traces for deprecations.
|
||||
This property is used instead of the `--trace-deprecation` command line flag.
|
||||
This property is instead of the `--trace-deprecation` command line flag.
|
||||
|
||||
### `process.traceProcessWarnings`
|
||||
|
||||
A `boolean` that controls whether or not process warnings printed to `stderr` include
|
||||
their stack trace. Setting this to `true` will print stack traces for process warnings
|
||||
(including deprecations). This property is used instead of the `--trace-warnings` command
|
||||
(including deprecations). This property is instead of the `--trace-warnings` command
|
||||
line flag.
|
||||
|
||||
### `process.type` _Readonly_
|
||||
|
||||
@@ -7,44 +7,21 @@ Process: [Main](../glossary.md#main-process)
|
||||
This module adds extra protection to data being stored on disk by using OS-provided cryptography systems. Current
|
||||
security semantics for each platform are outlined below.
|
||||
|
||||
> [!NOTE]
|
||||
> We recommend using the asynchronous API (`encryptStringAsync`/`decryptStringAsync`) over the synchronous API.
|
||||
> The async API is non-blocking, supports key rotation, and handles temporary unavailability gracefully.
|
||||
> The synchronous API may be deprecated in a future version of Electron.
|
||||
|
||||
## Platform-Specific Key Providers
|
||||
|
||||
### Synchronous API
|
||||
|
||||
* **macOS**: Encryption keys are stored for your app in [Keychain Access](https://support.apple.com/en-ca/guide/keychain-access/kyca1083/mac) in a way that prevents
|
||||
other applications from loading them without user override. Therefore, content is protected from other users and other apps running in the same userspace.
|
||||
* **Windows**: Encryption keys are generated via [DPAPI](https://learn.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptprotectdata). As per the Windows documentation: "Typically, only a user with the same logon credential as the user who encrypted the data can typically decrypt the data". Therefore, content is protected from other users on the same machine, but not from other apps running in the
|
||||
* **Windows**: Encryption keys are generated via [DPAPI](https://learn.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptprotectdata).
|
||||
As per the Windows documentation: "Typically, only a user with the same logon credential as the user who encrypted the data can typically
|
||||
decrypt the data". Therefore, content is protected from other users on the same machine, but not from other apps running in the
|
||||
same userspace.
|
||||
* **Linux**: Encryption keys are generated and stored in a secret store that varies depending on your window manager and system setup. Options currently supported are `kwallet`, `kwallet5`, `kwallet6` and `gnome-libsecret`, but more may be available in future versions of Electron. As such, the
|
||||
security semantics of content protected via the `safeStorage` API vary between window managers and secret stores.
|
||||
* Note that not all Linux setups have an available secret store. If no secret store is available, items stored in using the `safeStorage` API will be unprotected as they are encrypted via hardcoded plaintext password. You can detect when this happens when `safeStorage.getSelectedStorageBackend()` returns `basic_text`.
|
||||
* Note that not all Linux setups have an available secret store. If no secret store is available, items stored in using the `safeStorage` API will be unprotected
|
||||
as they are encrypted via hardcoded plaintext password. You can detect when this happens when `safeStorage.getSelectedStorageBackend()` returns `basic_text`.
|
||||
|
||||
Note that on macOS, access to the system Keychain is required and
|
||||
Note that on Mac, access to the system Keychain is required and
|
||||
these calls can block the current thread to collect user input.
|
||||
The same is true for Linux, if a password management tool is available.
|
||||
|
||||
### Asynchronous API
|
||||
|
||||
The asynchronous API uses pluggable key providers that vary by platform:
|
||||
|
||||
* **macOS**: Encryption keys are stored and retrieved from [Keychain Access](https://developer.apple.com/documentation/security/keychain-items). This provides the same security model as the synchronous API, protecting content from other users and other apps running in the same userspace.
|
||||
* **Windows**: Encryption keys are protected via [DPAPI](https://learn.microsoft.com/en-us/windows/win32/api/dpapi). This provides the same security model as the synchronous API, protecting content from other users on the same machine but not from other apps running in the same userspace.
|
||||
* **Linux**: Multiple key providers may be available depending on the desktop environment:
|
||||
* [`org.freedesktop.portal.Secret`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Secret.html): Uses the Portal Secret D-Bus interface to retrieve application-specific secrets. This is the preferred provider for sandboxed environments like Flatpak.
|
||||
* [Secret Service API](https://specifications.freedesktop.org/secret-service/latest/): Uses the freedesktop.org Secret Service API (e.g., GNOME Keyring) for key storage.
|
||||
* A fallback provider is used for environments without a secret service available.
|
||||
|
||||
Unlike the synchronous API, these operations are non-blocking and support additional features like key rotation (indicated by `shouldReEncrypt`) and temporary unavailability handling (indicated by `isTemporarilyUnavailable`).
|
||||
|
||||
## Events
|
||||
|
||||
The `safeStorage` module emits the following events:
|
||||
|
||||
## Methods
|
||||
|
||||
The `safeStorage` module has the following methods:
|
||||
@@ -57,10 +34,6 @@ On Linux, returns true if the app has emitted the `ready` event and the secret k
|
||||
On MacOS, returns true if Keychain is available.
|
||||
On Windows, returns true once the app has emitted the `ready` event.
|
||||
|
||||
### `safeStorage.isAsyncEncryptionAvailable()`
|
||||
|
||||
Returns `Promise<Boolean>` - Whether encryption is available for asynchronous safeStorage operations.
|
||||
|
||||
### `safeStorage.encryptString(plainText)`
|
||||
|
||||
* `plainText` string
|
||||
@@ -76,21 +49,7 @@ This function will throw an error if encryption fails.
|
||||
Returns `string` - the decrypted string. Decrypts the encrypted buffer
|
||||
obtained with `safeStorage.encryptString` back into a string.
|
||||
|
||||
### `safeStorage.encryptStringAsync(plainText)`
|
||||
|
||||
* `plainText` string
|
||||
|
||||
Returns `Promise<Buffer>` - An array of bytes representing the encrypted string.
|
||||
|
||||
### `safeStorage.decryptStringAsync(encrypted)`
|
||||
|
||||
* `encrypted` Buffer
|
||||
|
||||
Returns `Promise<Object>` - Resolve with an object containing the following:
|
||||
|
||||
* `shouldReEncrypt` boolean - whether data that has just been returned from the decrypt operation should be
|
||||
re-encrypted, as the key has been rotated or a new key is available that provides a different security level. If `true`, you should call `decryptStringAsync` again to receive the new decrypted string.
|
||||
* `result` string - the decrypted string.
|
||||
This function will throw an error if decryption fails.
|
||||
|
||||
### `safeStorage.setUsePlainTextEncryption(usePlainText)`
|
||||
|
||||
|
||||
@@ -1216,7 +1216,7 @@ function createWindow () {
|
||||
|
||||
mainWindow.webContents.session.setBluetoothPairingHandler((details, callback) => {
|
||||
bluetoothPinCallback = callback
|
||||
// Send an IPC message to the renderer to prompt the user to confirm the pairing.
|
||||
// Send a IPC message to the renderer to prompt the user to confirm the pairing.
|
||||
// Note that this will require logic in the renderer to handle this message and
|
||||
// display a prompt to the user.
|
||||
mainWindow.webContents.send('bluetooth-pairing-request', details)
|
||||
@@ -1264,7 +1264,7 @@ session.defaultSession.allowNTLMCredentialsForDomains('*')
|
||||
|
||||
Overrides the `userAgent` and `acceptLanguages` for this session.
|
||||
|
||||
The `acceptLanguages` must be a comma separated ordered list of language codes, for
|
||||
The `acceptLanguages` must a comma separated ordered list of language codes, for
|
||||
example `"en-US,fr,de,ko,zh-CN,ja"`.
|
||||
|
||||
This doesn't affect existing `WebContents`, and each `WebContents` can use
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# sharedTexture
|
||||
|
||||
> Import shared textures into Electron and converts platform specific handles into [`VideoFrame`](https://developer.mozilla.org/en-US/docs/Web/API/VideoFrame). Supports all Web rendering systems, and can be transferred across Electron processes. Read [here](../../shell/common/api/shared_texture/README.md) for more information.
|
||||
> Import shared textures into Electron and converts platform specific handles into [`VideoFrame`](https://developer.mozilla.org/en-US/docs/Web/API/VideoFrame). Supports all Web rendering systems, and can be transferred across Electron processes. Read [here](https://github.com/electron/electron/blob/main/shell/common/api/shared_texture/README.md) for more information.
|
||||
|
||||
Process: [Main](../glossary.md#main-process), [Renderer](../glossary.md#renderer-process)
|
||||
|
||||
@@ -21,7 +21,7 @@ Imports the shared texture from the given options.
|
||||
> [!NOTE]
|
||||
> This method is only available in the main process.
|
||||
|
||||
Returns [`SharedTextureImported`](structures/shared-texture-imported.md) - The imported shared texture.
|
||||
Returns `SharedTextureImported` - The imported shared texture.
|
||||
|
||||
### `sharedTexture.sendSharedTexture(options, ...args)` _Experimental_
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
* `depthPerComponent` number - The number of bits per color component.
|
||||
* `detected` boolean - `true` if the display is detected by the system.
|
||||
* `displayFrequency` number - The display refresh rate.
|
||||
* `id` number - Unique identifier associated with the display. A value of -1 means the display is invalid or the correct `id` is not yet known, and a value of -10 means the display is a virtual display assigned to a unified desktop.
|
||||
* `id` number - Unique identifier associated with the display. A value of of -1 means the display is invalid or the correct `id` is not yet known, and a value of -10 means the display is a virtual display assigned to a unified desktop.
|
||||
* `internal` boolean - `true` for an internal display and `false` for an external display.
|
||||
* `label` string - User-friendly label, determined by the platform.
|
||||
* `maximumCursorSize` [Size](size.md) - Maximum cursor size in native pixels.
|
||||
|
||||
@@ -1,15 +1,13 @@
|
||||
# NotificationAction Object
|
||||
|
||||
* `type` string - The type of action, can be `button` or `selection`. `selection` is only supported on Windows.
|
||||
* `type` string - The type of action, can be `button`.
|
||||
* `text` string (optional) - The label for the given action.
|
||||
* `items` string[] (optional) _Windows_ - The list of items for the `selection` action `type`.
|
||||
|
||||
## Platform / Action Support
|
||||
|
||||
| Action Type | Platform Support | Usage of `text` | Default `text` | Limitations |
|
||||
|-------------|------------------|-----------------|----------------|-------------|
|
||||
| `button` | macOS, Windows | Used as the label for the button | "Show" on macOS (localized) if first `button`, otherwise empty; Windows uses provided `text` | macOS: Only the first one is used as primary; others shown as additional actions (hover). Incompatible with `hasReply` (beyond first ignored). |
|
||||
| `selection` | Windows | Used as the label for the submit button for the selection menu | "Select" | Requires an `items` array property specifying option labels. Emits the `action` event with `(index, selectedIndex)` where `selectedIndex` is the chosen option (>= 0). Ignored on platforms that do not support selection actions. |
|
||||
| `button` | macOS | Used as the label for the button | "Show" (or a localized string by system default if first of such `button`, otherwise empty) | Only the first one is used. If multiple are provided, those beyond the first will be listed as additional actions (displayed when mouse active over the action button). Any such action also is incompatible with `hasReply` and will be ignored if `hasReply` is `true`. |
|
||||
|
||||
### Button support on macOS
|
||||
|
||||
@@ -17,37 +15,6 @@ In order for extra notification buttons to work on macOS your app must meet the
|
||||
following criteria.
|
||||
|
||||
* App is signed
|
||||
* App has its `NSUserNotificationAlertStyle` set to `alert` in the `Info.plist`.
|
||||
* App has it's `NSUserNotificationAlertStyle` set to `alert` in the `Info.plist`.
|
||||
|
||||
If either of these requirements are not met the button won't appear.
|
||||
|
||||
### Selection support on Windows
|
||||
|
||||
To add a selection (combo box) style action, include an action with `type: 'selection'`, a `text` label for the submit button, and an `items` array of strings:
|
||||
|
||||
```js
|
||||
const { Notification, app } = require('electron')
|
||||
|
||||
app.whenReady().then(() => {
|
||||
const items = ['One', 'Two', 'Three']
|
||||
const n = new Notification({
|
||||
title: 'Choose an option',
|
||||
actions: [{
|
||||
type: 'selection',
|
||||
text: 'Apply',
|
||||
items
|
||||
}]
|
||||
})
|
||||
|
||||
n.on('action', (e) => {
|
||||
console.log(`User triggered action at index: ${e.actionIndex}`)
|
||||
if (e.selectionIndex > 0) {
|
||||
console.log(`User chose selection item '${items[e.selectionIndex]}'`)
|
||||
}
|
||||
})
|
||||
|
||||
n.show()
|
||||
})
|
||||
```
|
||||
|
||||
When the user activates the selection action, the notification's `action` event will be emitted with two parameters: `actionIndex` (the action's index in the `actions` array) and `selectedIndex` (the zero-based index of the chosen item, or `-1` if unavailable). On non-Windows platforms selection actions are ignored.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# SharedTextureHandle Object
|
||||
|
||||
* `ntHandle` Buffer (optional) _Windows_ - NT HANDLE holds the shared texture. Note that this NT HANDLE is local to current process. Output textures of `rgba`, `bgra`, `rgbaf16` formats don't have a keyed mutex on the texture handle, but `nv12` format texture handles do have a keyed mutex.
|
||||
* `ntHandle` Buffer (optional) _Windows_ - NT HANDLE holds the shared texture. Note that this NT HANDLE is local to current process.
|
||||
* `ioSurface` Buffer (optional) _macOS_ - IOSurfaceRef holds the shared texture. Note that this IOSurface is local to current process (not global).
|
||||
* `nativePixmap` Object (optional) _Linux_ - Structure contains planes of shared texture.
|
||||
* `planes` Object[] _Linux_ - Each plane's info of the shared texture.
|
||||
|
||||
@@ -40,7 +40,7 @@
|
||||
* `javascript` boolean (optional) - Enables JavaScript support. Default is `true`.
|
||||
* `webSecurity` boolean (optional) - When `false`, it will disable the
|
||||
same-origin policy (usually using testing websites by people), and set
|
||||
`allowRunningInsecureContent` to `true` if this option has not been set
|
||||
`allowRunningInsecureContent` to `true` if this options has not been set
|
||||
by user. Default is `true`.
|
||||
* `allowRunningInsecureContent` boolean (optional) - Allow an https page to run
|
||||
JavaScript, CSS or plugins from http URLs. Default is `false`.
|
||||
@@ -94,7 +94,7 @@
|
||||
The actual output pixel format and color space of the texture should refer to [`OffscreenSharedTexture`](../structures/offscreen-shared-texture.md) object in the `paint` event.
|
||||
* `argb` - The requested output texture format is 8-bit unorm RGBA, with SRGB SDR color space.
|
||||
* `rgbaf16` - The requested output texture format is 16-bit float RGBA, with scRGB HDR color space.
|
||||
* `deviceScaleFactor` number (optional) _Experimental_ - The device scale factor of the offscreen rendering output. If not set, will use `1` as default.
|
||||
* `deviceScaleFactor` number (optional) _Experimental_ - The device scale factor of the offscreen rendering output. If not set, will use primary display's scale factor as default.
|
||||
* `contextIsolation` boolean (optional) - Whether to run Electron APIs and
|
||||
the specified `preload` script in a separate JavaScript context. Defaults
|
||||
to `true`. The context that the `preload` script runs in will only have
|
||||
|
||||
@@ -23,6 +23,11 @@ Creates a new touch bar with the specified items. Use
|
||||
> The TouchBar API is currently experimental and may change or be
|
||||
> removed in future Electron releases.
|
||||
|
||||
> [!TIP]
|
||||
> If you don't have a MacBook with Touch Bar, you can use
|
||||
> [Touch Bar Simulator](https://github.com/sindresorhus/touch-bar-simulator)
|
||||
> to test Touch Bar usage in your app.
|
||||
|
||||
### Static Properties
|
||||
|
||||
#### `TouchBarButton`
|
||||
|
||||
@@ -383,7 +383,7 @@ Emitted after a server side redirect occurs during navigation. For example a 30
|
||||
redirect.
|
||||
|
||||
This event cannot be prevented, if you want to prevent redirects you should
|
||||
check out the `will-redirect` event above.
|
||||
checkout out the `will-redirect` event above.
|
||||
|
||||
#### Event: 'did-navigate'
|
||||
|
||||
@@ -933,7 +933,7 @@ copying data between CPU and GPU memory, with Chromium's hardware acceleration s
|
||||
Only a limited number of textures can exist at the same time, so it's important that you call `texture.release()` as soon as you're done with the texture.
|
||||
By managing the texture lifecycle by yourself, you can safely pass the `texture.textureInfo` to other processes through IPC.
|
||||
|
||||
More details can be found in the [offscreen rendering tutorial](../tutorial/offscreen-rendering.md). To learn about how to handle the texture in native code, refer to [offscreen rendering's code documentation.](../../shell/browser/osr/README.md).
|
||||
More details can be found in the [offscreen rendering tutorial](../tutorial/offscreen-rendering.md). To learn about how to handle the texture in native code, refer to [offscreen rendering's code documentation.](https://github.com/electron/electron/blob/main/shell/browser/osr/README.md).
|
||||
|
||||
```js
|
||||
const { BrowserWindow } = require('electron')
|
||||
@@ -1465,7 +1465,7 @@ Ignore application menu shortcuts while this web contents is focused.
|
||||
without a recognized 'action' value will result in a console error and have
|
||||
the same effect as returning `{action: 'deny'}`.
|
||||
|
||||
Called before creating a window when a new window is requested by the renderer, e.g.
|
||||
Called before creating a window a new window is requested by the renderer, e.g.
|
||||
by `window.open()`, a link with `target="_blank"`, shift+clicking on a link, or
|
||||
submitting a form with `<form target="_blank">`. See
|
||||
[`window.open()`](window-open.md) for more details and how to use this in
|
||||
@@ -1748,12 +1748,11 @@ Returns `Promise<PrinterInfo[]>` - Resolves with a [`PrinterInfo[]`](structures/
|
||||
* `footer` string (optional) - string to be printed as page footer.
|
||||
* `pageSize` string | Size (optional) - Specify page size of the printed document. Can be `A0`, `A1`, `A2`, `A3`,
|
||||
`A4`, `A5`, `A6`, `Legal`, `Letter`, `Tabloid` or an Object containing `height` and `width`.
|
||||
* `usePrinterDefaultPageSize` boolean (optional) - Whether to use a given printer's default page size. Default is `false`. Cannot be combined with `pageSize`. When `deviceName` is provided, uses the default page size of that specific printer. When `deviceName` is not provided, uses the default page size of the system's default printer. If the printer's default page size cannot be retrieved, falls back to A4 (210mm x 297mm).
|
||||
* `callback` Function (optional)
|
||||
* `success` boolean - Indicates success of the print call.
|
||||
* `failureReason` string - Error description called back if the print fails.
|
||||
|
||||
When a custom `pageSize` is passed, Chromium attempts to validate platform specific minimum values for `width_microns` and `height_microns`. Width and height must both be minimum 353 microns but may be higher on some operating systems. If a valid `pageSize` is not passed and `usePrinterDefaultPageSize` is `false`, an error will be thrown.
|
||||
When a custom `pageSize` is passed, Chromium attempts to validate platform specific minimum values for `width_microns` and `height_microns`. Width and height must both be minimum 353 microns but may be higher on some operating systems.
|
||||
|
||||
Prints window's web page. When `silent` is set to `true`, Electron will pick
|
||||
the system's default printer if `deviceName` is empty and the default settings for printing.
|
||||
@@ -2370,7 +2369,7 @@ instance that might own this `WebContents`.
|
||||
|
||||
#### `contents.devToolsWebContents` _Readonly_
|
||||
|
||||
A `WebContents | null` property that represents the DevTools `WebContents` associated with a given `WebContents`.
|
||||
A `WebContents | null` property that represents the of DevTools `WebContents` associated with a given `WebContents`.
|
||||
|
||||
> [!NOTE]
|
||||
> Users should never store this object because it may become `null`
|
||||
|
||||
@@ -588,7 +588,6 @@ Stops any `findInPage` request for the `webview` with the provided `action`.
|
||||
* `footer` string (optional) - string to be printed as page footer.
|
||||
* `pageSize` string | Size (optional) - Specify page size of the printed document. Can be `A3`,
|
||||
`A4`, `A5`, `Legal`, `Letter`, `Tabloid` or an Object containing `height` in microns.
|
||||
* `usePrinterDefaultPageSize` boolean (optional) - Whether to use the system's default page size. Default is `false`. Cannot be combined with `pageSize`. When `deviceName` is provided, uses the default page size of that specific printer. When `deviceName` is not provided, uses the default page size of the system's default printer. If the printer's default page size cannot be retrieved, falls back to A4 (210mm x 297mm).
|
||||
|
||||
Returns `Promise<void>`
|
||||
|
||||
|
||||
@@ -24,35 +24,6 @@ for more consistent output sizes.
|
||||
|
||||
## Planned Breaking API Changes (41.0)
|
||||
|
||||
### Behavior Changed: `electron` no longer downloads itself via `postinstall` script
|
||||
|
||||
Previously, the `electron` npm package would download the Electron binary from the repository's
|
||||
GitHub Releases in the package's `postinstall` script.
|
||||
|
||||
With recent supply chain security attacks against the npm ecosystem with `postinstall` scripts as a
|
||||
common attack vector, Electron will now download itself dynamically the first time that its main
|
||||
`bin` script is run (e.g. via `npx electron`). With this change, you can now use Electron with the
|
||||
npm `--ignore-scripts` flag. See [RFC #22](https://github.com/electron/rfcs/pull/22) for more context.
|
||||
|
||||
```sh
|
||||
# won't install binary to `node_modules/electron`
|
||||
npm install electron --save-dev --ignore-scripts
|
||||
|
||||
# will download the binary on demand before starting electron process
|
||||
npx electron .
|
||||
|
||||
# subsequent runs will used the binary downloaded from the first run
|
||||
npx electron .
|
||||
```
|
||||
|
||||
If you need to download the Electron binary on-demand, you can now call the `install-electron` script,
|
||||
which contains the exact same code from the former `postinstall` script.
|
||||
|
||||
```sh
|
||||
npm install electron --save-dev --ignore-scripts
|
||||
npx install-electron --no
|
||||
```
|
||||
|
||||
### Behavior Changed: PDFs no longer create a separate WebContents
|
||||
|
||||
Previously, PDF resources created a separate guest [WebContents](https://www.electronjs.org/docs/latest/api/web-contents) for rendering. Now, PDFs are rendered within the same WebContents instead. If you have code to detect PDF resources, use the [frame tree](https://www.electronjs.org/docs/latest/api/web-frame-main) instead of WebContents.
|
||||
@@ -105,22 +76,6 @@ webContents.setWindowOpenHandler((details) => {
|
||||
})
|
||||
```
|
||||
|
||||
### Behavior Changed: `NSAudioCaptureUsageDescription` should be included in your app's Info.plist file to use `desktopCapturer` (🍏 macOS ≥14.2)
|
||||
|
||||
Per [Chromium update](https://source.chromium.org/chromium/chromium/src/+/ad17e8f8b93d5f34891b06085d373a668918255e) which enables Apple's newer [CoreAudio Tap API](https://developer.apple.com/documentation/CoreAudio/capturing-system-audio-with-core-audio-taps#Configure-the-sample-code-project) by default, you now must have `NSAudioCaptureUsageDescription` defined in your `Info.plist` to use `desktopCapturer`.
|
||||
|
||||
Electron's `desktopCapturer` will create a dead audio stream if the new permission is absent however no errors or warnings will occur. This is partially a side-effect of Chromium not falling back to the older `Screen & System Audio Recording` permissions system if the new system fails.
|
||||
|
||||
To restore previous behavior:
|
||||
|
||||
```js
|
||||
// main.js (right beneath your require/import statments)
|
||||
app.commandLine.appendSwitch(
|
||||
'disable-features',
|
||||
'MacCatapLoopbackAudioForScreenShare'
|
||||
)
|
||||
```
|
||||
|
||||
### Behavior Changed: shared texture OSR `paint` event data structure
|
||||
|
||||
When using shared texture offscreen rendering feature, the `paint` event now emits a more structured object.
|
||||
@@ -139,7 +94,7 @@ Users can force XWayland by passing `--ozone-platform=x11`.
|
||||
### Removed: `ORIGINAL_XDG_CURRENT_DESKTOP` environment variable
|
||||
|
||||
Previously, Electron changed the value of `XDG_CURRENT_DESKTOP` internally to `Unity`, and stored the original name of the desktop session
|
||||
in a separate variable. `XDG_CURRENT_DESKTOP` is no longer overridden and now reflects the actual desktop environment.
|
||||
in a separate variable. `XDG_CURRENT_DESKTOP` is no longer overriden and now reflects the actual desktop environment.
|
||||
|
||||
### Removed: macOS 11 support
|
||||
|
||||
@@ -220,7 +175,7 @@ window is not currently visible.
|
||||
|
||||
`app.commandLine` was only meant to handle chromium switches (which aren't case-sensitive) and switches passed via `app.commandLine` will not be passed down to any of the child processes.
|
||||
|
||||
If you were using `app.commandLine` to control the behavior of the main process, you should do this via `process.argv`.
|
||||
If you were using `app.commandLine` to control the behavior of the main process, you should do this via `process.argv`.
|
||||
|
||||
### Deprecated: `NativeImage.getBitmap()`
|
||||
|
||||
@@ -250,7 +205,7 @@ from upstream Chromium.
|
||||
### Deprecated: `null` value for `session` property in `ProtocolResponse`
|
||||
|
||||
Previously, setting the ProtocolResponse.session property to `null`
|
||||
would create a random independent session. This is no longer supported.
|
||||
Would create a random independent session. This is no longer supported.
|
||||
|
||||
Using single-purpose sessions here is discouraged due to overhead costs;
|
||||
however, old code that needs to preserve this behavior can emulate it by
|
||||
@@ -261,7 +216,7 @@ and then using it in `ProtocolResponse.session`.
|
||||
|
||||
When calling `Session.clearStorageData(options)`, the `options.quota`
|
||||
property is deprecated. Since the `syncable` type was removed, there
|
||||
is only one type left -- `'temporary'` -- so specifying it is unnecessary.
|
||||
is only type left -- `'temporary'` -- so specifying it is unnecessary.
|
||||
|
||||
### Deprecated: Extension methods and events on `session`
|
||||
|
||||
@@ -590,7 +545,7 @@ more information.
|
||||
|
||||
### Removed: The `--disable-color-correct-rendering` switch
|
||||
|
||||
This switch was never formally documented but its removal is being noted here regardless. Chromium itself now has better support for color spaces so this flag should not be needed.
|
||||
This switch was never formally documented but it's removal is being noted here regardless. Chromium itself now has better support for color spaces so this flag should not be needed.
|
||||
|
||||
### Behavior Changed: `BrowserView.setAutoResize` behavior on macOS
|
||||
|
||||
@@ -1281,7 +1236,7 @@ more details.
|
||||
|
||||
### API Changed: `webContents.printToPDF()`
|
||||
|
||||
`webContents.printToPDF()` has been modified to conform to [`Page.printToPDF`](https://chromedevtools.github.io/devtools-protocol/tot/Page/#method-printToPDF) in the Chrome DevTools Protocol. This has been changed in order to
|
||||
`webContents.printToPDF()` has been modified to conform to [`Page.printToPDF`](https://chromedevtools.github.io/devtools-protocol/tot/Page/#method-printToPDF) in the Chrome DevTools Protocol. This has been changes in order to
|
||||
address changes upstream that made our previous implementation untenable and rife with bugs.
|
||||
|
||||
**Arguments Changed**
|
||||
|
||||
@@ -41,7 +41,7 @@ e init --root=~/electron --bootstrap testing
|
||||
```
|
||||
|
||||
The `--bootstrap` flag also runs `e sync` (synchronizes source code branches from
|
||||
[`DEPS`](../../DEPS) using
|
||||
[`DEPS`](https://github.com/electron/electron/blob/main/DEPS) using
|
||||
[`gclient`](https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/HEAD/README.gclient.md))
|
||||
and `e build` (compiles the Electron binary into the `${root}/src/out` folder).
|
||||
|
||||
@@ -63,7 +63,7 @@ Some quick tips on building once your checkout is set up:
|
||||
* **Updating your checkout:** Run git commands such as `git checkout <branch>` and `git pull` from `${root}/src/electron`.
|
||||
Whenever you update your commit `HEAD`, make sure to `e sync` before `e build` to sync dependencies
|
||||
such as Chromium and Node.js. This is especially relevant because the Chromium version in
|
||||
[`DEPS`](../../DEPS) changes frequently.
|
||||
[`DEPS`](https://github.com/electron/electron/blob/main/DEPS) changes frequently.
|
||||
* **Rebuilding:** When making changes to code in `${root}/src/electron/` in a local branch, you only need to re-run `e build`.
|
||||
* **Adding patches:** When contributing changes in `${root}/src/` outside of `${root}/src/electron/`, you need to do so
|
||||
via Electron's [patch system](./patches.md). The `e patches` command can export all relevant patches to
|
||||
@@ -98,7 +98,7 @@ Project configurations can be found in the `.gn` and `.gni` files in the `electr
|
||||
|
||||
The following `gn` files contain the main rules for building Electron:
|
||||
|
||||
* [`BUILD.gn`](../../BUILD.gn) defines how Electron itself
|
||||
* [`BUILD.gn`](https://github.com/electron/electron/blob/main/BUILD.gn) defines how Electron itself
|
||||
is built and includes the default configurations for linking with Chromium.
|
||||
* [`build/args/{testing,release,all}.gn`](https://github.com/electron/electron/tree/main/build/args)
|
||||
contain the default build arguments for building Electron.
|
||||
|
||||
@@ -40,7 +40,7 @@ If you are on arm64 architecture, the build script may be pointing to the wrong
|
||||
|
||||
### Certificates fail to verify
|
||||
|
||||
Installing [`certifi`](https://pypi.org/project/certifi/) will fix the following error:
|
||||
installing [`certifi`](https://pypi.org/project/certifi/) will fix the following error:
|
||||
|
||||
```sh
|
||||
________ running 'python3 src/tools/clang/scripts/update.py' in '/Users/<user>/electron'
|
||||
|
||||
@@ -6,7 +6,7 @@ This is not a comprehensive end-all guide to creating an Electron Browser API, r
|
||||
|
||||
## Add your files to Electron's project configuration
|
||||
|
||||
Electron uses [GN](https://gn.googlesource.com/gn) as a meta build system to generate files for its compiler, [Ninja](https://ninja-build.org/). This means that in order to tell Electron to compile your code, we have to add your API's code and header file names into [`filenames.gni`](../../filenames.gni).
|
||||
Electron uses [GN](https://gn.googlesource.com/gn) as a meta build system to generate files for its compiler, [Ninja](https://ninja-build.org/). This means that in order to tell Electron to compile your code, we have to add your API's code and header file names into [`filenames.gni`](https://github.com/electron/electron/blob/main/filenames.gni).
|
||||
|
||||
You will need to append your API file names alphabetically into the appropriate files like so:
|
||||
|
||||
@@ -127,7 +127,7 @@ void Initialize(v8::Local<v8::Object> exports,
|
||||
|
||||
## Link your Electron API with Node
|
||||
|
||||
In the [`typings/internal-ambient.d.ts`](../../typings/internal-ambient.d.ts) file, we need to append a new property onto the `Process` interface like so:
|
||||
In the [`typings/internal-ambient.d.ts`](https://github.com/electron/electron/blob/main/typings/internal-ambient.d.ts) file, we need to append a new property onto the `Process` interface like so:
|
||||
|
||||
```ts title='typings/internal-ambient.d.ts' @ts-nocheck
|
||||
interface Process {
|
||||
@@ -141,7 +141,7 @@ At the very bottom of your `api_name.cc` file:
|
||||
NODE_LINKED_BINDING_CONTEXT_AWARE(electron_browser_{api_name},Initialize)
|
||||
```
|
||||
|
||||
In your [`shell/common/node_bindings.cc`](../../shell/common/node_bindings.cc) file, add your node binding name to Electron's built-in modules.
|
||||
In your [`shell/common/node_bindings.cc`](https://github.com/electron/electron/blob/main/shell/common/node_bindings.cc) file, add your node binding name to Electron's built-in modules.
|
||||
|
||||
```cpp title='shell/common/node_bindings.cc'
|
||||
#define ELECTRON_BROWSER_MODULES(V) \
|
||||
@@ -159,7 +159,7 @@ We will need to create a new TypeScript file in the path that follows:
|
||||
|
||||
`"lib/browser/api/{electron_browser_{api_name}}.ts"`
|
||||
|
||||
An example of the contents of this file can be found [here](../../lib/browser/api/native-theme.ts).
|
||||
An example of the contents of this file can be found [here](https://github.com/electron/electron/blob/main/lib/browser/api/native-theme.ts).
|
||||
|
||||
### Expose your module to TypeScript
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ with breakpoints inside Electron's source code.
|
||||
format.
|
||||
|
||||
* **ProcMon**: The [free SysInternals tool][sys-internals] allows you to inspect
|
||||
a process's parameters, file handles, and registry operations.
|
||||
a processes parameters, file handles, and registry operations.
|
||||
|
||||
## Attaching to and Debugging Electron
|
||||
|
||||
|
||||
@@ -86,6 +86,12 @@ Note that multiple commits get squashed when they are landed.
|
||||
The `electron/electron` repo enforces [commit signatures](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) for all incoming PRs.
|
||||
To sign your commits, see GitHub's documentation on [Telling Git about your signing key](https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key).
|
||||
|
||||
##### Pre-push hook verification
|
||||
|
||||
A pre-push Git hook automatically verifies that all commits being pushed are signed. If unsigned commits are detected, the push will be rejected with error messages detailing the unsigned commits.
|
||||
|
||||
This verification can also be run manually via `npm run check-signed-commits`.
|
||||
|
||||
#### Commit message guidelines
|
||||
|
||||
A good commit message should describe what changed and why. The Electron project
|
||||
@@ -185,7 +191,7 @@ $ git push origin my-branch
|
||||
### Step 9: Opening the Pull Request
|
||||
|
||||
From within GitHub, opening a new pull request will present you with a template
|
||||
that should be filled out. It can be found [here](../../.github/PULL_REQUEST_TEMPLATE.md).
|
||||
that should be filled out. It can be found [here](https://github.com/electron/electron/blob/main/.github/PULL_REQUEST_TEMPLATE.md).
|
||||
|
||||
If you do not adequately complete this template, your PR may be delayed in being merged as maintainers
|
||||
seek more information or clarify ambiguities.
|
||||
@@ -218,7 +224,8 @@ seem unfamiliar, refer to this
|
||||
|
||||
#### Approval and Request Changes Workflow
|
||||
|
||||
All pull requests require approval from a [Code Owner](../../.github/CODEOWNERS)
|
||||
All pull requests require approval from a
|
||||
[Code Owner](https://github.com/electron/electron/blob/main/.github/CODEOWNERS)
|
||||
of the area you modified in order to land. Whenever a maintainer reviews a pull
|
||||
request they may request changes. These may be small, such as fixing a typo, or
|
||||
may involve substantive changes. Such requests are intended to be helpful, but
|
||||
|
||||
@@ -10,11 +10,11 @@ to understand the source code better.
|
||||
## Project structure
|
||||
|
||||
Electron is a complex project containing multiple upstream dependencies, which are tracked in source
|
||||
control via the [`DEPS`](../../DEPS) file. When
|
||||
control via the [`DEPS`](https://github.com/electron/electron/blob/main/DEPS) file. When
|
||||
[initializing a local Electron checkout](./build-instructions-gn.md), Electron's source code is just one
|
||||
of many nested folders within the project root.
|
||||
|
||||
The project contains a single `src` folder that corresponds to a specific git checkout of
|
||||
The project contains a single `src` folder that corresponds a specific git checkout of
|
||||
[Chromium's `src` folder](https://source.chromium.org/chromium/chromium/src). In addition, Electron's
|
||||
repository code is contained in `src/electron` (with its own nested git repository), and other
|
||||
Electron-specific third-party dependencies (e.g. [nan](https://github.com/nodejs/nan) or
|
||||
|
||||
@@ -17,7 +17,7 @@ style, run `npm run lint`, which will run a variety of linting checks
|
||||
against your changes depending on which areas of the code they touch.
|
||||
|
||||
Many of these checks are included as precommit hooks, so it's likely
|
||||
your error would be caught at commit time.
|
||||
you error would be caught at commit time.
|
||||
|
||||
## Unit Tests
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ dependency tree from `node_modules`).
|
||||
|
||||
### ASAR integrity
|
||||
|
||||
ASAR integrity is a security feature that validates the contents of your app's
|
||||
ASAR integrity is an security feature that validates the contents of your app's
|
||||
ASAR archives at runtime. When enabled, your Electron app will verify the
|
||||
header hash of its ASAR archive on runtime. If no hash is present or if there is a mismatch in the
|
||||
hashes, the app will forcefully terminate.
|
||||
@@ -137,9 +137,9 @@ See also: [code signing](#code-signing)
|
||||
|
||||
### OSR
|
||||
|
||||
OSR (offscreen rendering) can be used for loading a heavy page in
|
||||
OSR (offscreen rendering) can be used for loading heavy page in
|
||||
background and then displaying it after (it will be much faster).
|
||||
It allows you to render a page without showing it on screen.
|
||||
It allows you to render page without showing it on screen.
|
||||
|
||||
For more information, read the [Offscreen Rendering][] tutorial.
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ hide_title: false
|
||||
---
|
||||
|
||||
After creating an [application distribution](application-distribution.md), the
|
||||
app's source code is usually bundled into an [ASAR archive](https://github.com/electron/asar),
|
||||
app's source code are usually bundled into an [ASAR archive](https://github.com/electron/asar),
|
||||
which is a simple extensive archive format designed for Electron apps. By bundling the app
|
||||
we can mitigate issues around long path names on Windows, speed up `require` and conceal your source
|
||||
code from cursory inspection.
|
||||
@@ -134,7 +134,7 @@ 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 require extra unpacking are:
|
||||
APIs that requires extra unpacking are:
|
||||
|
||||
* `child_process.execFile`
|
||||
* `child_process.execFileSync`
|
||||
|
||||
@@ -15,14 +15,6 @@ Currently, ASAR integrity checking is supported on:
|
||||
* macOS as of `electron>=16.0.0`
|
||||
* Windows as of `electron>=30.0.0`
|
||||
|
||||
> [!NOTE]
|
||||
> ASAR integrity is fully supported in Mac App Store (MAS) builds and is recommended
|
||||
> as a best practice. While MAS-installed applications have their `Resources/` folder
|
||||
> protected by the system (owned by root), ASAR integrity still provides an additional
|
||||
> layer of security. It is especially important if you use Electron's MAS build but
|
||||
> distribute your app through channels other than the Mac App Store (such as direct
|
||||
> download), since those installations won't have the system-level read-only protections.
|
||||
|
||||
In order to enable ASAR integrity checking, you also need to ensure that your `app.asar` file
|
||||
was generated by a version of the `@electron/asar` npm package that supports ASAR integrity.
|
||||
|
||||
@@ -32,7 +24,7 @@ All versions of `@electron/asar` support ASAR integrity.
|
||||
## How it works
|
||||
|
||||
Each ASAR archive contains a JSON string header. The header format includes an `integrity` object
|
||||
that contains a hex encoded hash of the entire archive as well as an array of hex encoded hashes for each
|
||||
that contain a hex encoded hash of the entire archive as well as an array of hex encoded hashes for each
|
||||
block of `blockSize` bytes.
|
||||
|
||||
```json
|
||||
|
||||
@@ -203,7 +203,7 @@ test('launch app', async () => {
|
||||
})
|
||||
```
|
||||
|
||||
After that, you will have access to an instance of Playwright's `ElectronApp` class. This
|
||||
After that, you will access to an instance of Playwright's `ElectronApp` class. This
|
||||
is a powerful class that has access to main process modules for example:
|
||||
|
||||
```js {5-10} @ts-nocheck
|
||||
@@ -237,7 +237,7 @@ test('save screenshot', async () => {
|
||||
})
|
||||
```
|
||||
|
||||
Putting all this together using the Playwright test-runner, let's create an `example.spec.js`
|
||||
Putting all this together using the Playwright test-runner, let's create a `example.spec.js`
|
||||
test file with a single test and assertion:
|
||||
|
||||
```js title='example.spec.js' @ts-nocheck
|
||||
@@ -377,7 +377,7 @@ class TestDriver {
|
||||
module.exports = { TestDriver }
|
||||
```
|
||||
|
||||
In your app code, you can then write a simple handler to receive RPC calls:
|
||||
In your app code, can then write a simple handler to receive RPC calls:
|
||||
|
||||
```js title='main.js'
|
||||
const METHODS = {
|
||||
|
||||
@@ -17,7 +17,7 @@ run them, users need to go through multiple advanced and manual steps.
|
||||
|
||||
If you are building an Electron app that you intend to package and distribute,
|
||||
it should be code signed. The Electron ecosystem tooling makes codesigning your
|
||||
apps straightforward - this documentation explains how to sign your apps on both
|
||||
apps straightforward - this documentation explains how sign your apps on both
|
||||
Windows and macOS.
|
||||
|
||||
## Signing & notarizing macOS builds
|
||||
@@ -210,7 +210,7 @@ const msiCreator = new MSICreator({
|
||||
const supportBinaries = await msiCreator.create()
|
||||
|
||||
// 🆕 Step 2a: optionally sign support binaries if you
|
||||
// sign your binaries as part of your packaging script
|
||||
// sign you binaries as part of of your packaging script
|
||||
for (const binary of supportBinaries) {
|
||||
// Binaries are the new stub executable and optionally
|
||||
// the Squirrel auto updater.
|
||||
|
||||
@@ -110,7 +110,7 @@ const win = new BrowserWindow({
|
||||
#### Show and hide the traffic lights programmatically _macOS_
|
||||
|
||||
You can also show and hide the traffic lights programmatically from the main process.
|
||||
The `win.setWindowButtonVisibility` forces traffic lights to be shown or hidden depending
|
||||
The `win.setWindowButtonVisibility` forces traffic lights to be show or hidden depending
|
||||
on the value of its boolean parameter.
|
||||
|
||||
```js title='main.js'
|
||||
|
||||
@@ -5,12 +5,12 @@
|
||||
By default, windows are dragged using the title bar provided by the OS chrome. Apps
|
||||
that remove the default title bar need to use the `app-region` CSS property to define
|
||||
specific areas that can be used to drag the window. Setting `app-region: drag` marks
|
||||
a rectangular area as draggable.
|
||||
a rectagular area as draggable.
|
||||
|
||||
It is important to note that draggable areas ignore all pointer events. For example,
|
||||
a button element that overlaps a draggable region will not emit mouse clicks or mouse
|
||||
enter/exit events within that overlapping area. Setting `app-region: no-drag` reenables
|
||||
pointer events by excluding a rectangular area from a draggable region.
|
||||
pointer events by excluding a rectagular area from a draggable region.
|
||||
|
||||
To make the whole window draggable, you can add `app-region: drag` as
|
||||
`body`'s style:
|
||||
|
||||
@@ -29,7 +29,7 @@ be updated accordingly.
|
||||
In macOS 10.14 Mojave, Apple introduced a new [system-wide dark mode][system-wide-dark-mode]
|
||||
for all macOS computers. If your Electron app has a dark mode, you can make it
|
||||
follow the system-wide dark mode setting using
|
||||
[the `nativeTheme` API](../api/native-theme.md).
|
||||
[the `nativeTheme` api](../api/native-theme.md).
|
||||
|
||||
In macOS 10.15 Catalina, Apple introduced a new "automatic" dark mode option
|
||||
for all macOS computers. In order for the `nativeTheme.shouldUseDarkColors` and
|
||||
|
||||
@@ -137,33 +137,6 @@ The extra privileges granted to the `file://` protocol by this fuse are incomple
|
||||
* `file://` protocol pages have universal access granted to child frames also running on `file://`
|
||||
protocols regardless of sandbox settings
|
||||
|
||||
### `wasmTrapHandlers`
|
||||
|
||||
**Default:** Enabled
|
||||
|
||||
**@electron/fuses:** `FuseV1Options.WasmTrapHandlers`
|
||||
|
||||
The `wasmTrapHandlers` fuse controls whether V8 will use signal handlers to trap Out of Bounds memory
|
||||
access from WebAssembly. The feature works by surrounding the WebAssembly memory with large guard regions
|
||||
and then installing a signal handler that traps attempt to access memory in the guard region. The feature
|
||||
is only supported on the following 64-bit systems.
|
||||
|
||||
Linux. MacOS, Windows - x86_64
|
||||
Linux, MacOS - aarch64
|
||||
|
||||
| Guard Pages | WASM heap | Guard Pages |
|
||||
|-----8GB-----| |-----8GB-----|
|
||||
|
||||
When the fuse is disabled V8 will use explicit bound checks in the generated WebAssembly code to ensure
|
||||
memory safety. However, this method has some downsides
|
||||
|
||||
* The compiler generates extra nodes for each memory reference, leading to longer compile times due to the
|
||||
additional processing time needed for these nodes.
|
||||
* In turn, these extra nodes lead to lots of extra code being generated, making WebAssembly modules bigger
|
||||
than they ideally should be.
|
||||
* This extra code, particularly the compare and branch before every memory reference,
|
||||
incurs a significant runtime cost.
|
||||
|
||||
## How do I flip fuses?
|
||||
|
||||
### The easy way
|
||||
@@ -224,4 +197,4 @@ Somewhere in the Electron binary, there will be a sequence of bytes that look li
|
||||
|
||||
To flip a fuse, you find its position in the fuse wire and change it to "0" or "1" depending on the state you'd like.
|
||||
|
||||
You can view the current schema [here](../../build/fuses/fuses.json5).
|
||||
You can view the current schema [here](https://github.com/electron/electron/blob/main/build/fuses/fuses.json5).
|
||||
|
||||
@@ -11,30 +11,6 @@ npm install electron --save-dev
|
||||
See the [Electron versioning doc][versioning] for info on how to
|
||||
manage Electron versions in your apps.
|
||||
|
||||
## Binary download step
|
||||
|
||||
Under the hood, Electron's JavaScript API binds to a binary that contains its
|
||||
implementations. This binary is crucial to the function of any Electron app, and
|
||||
is downloaded by default the first time you run Electron in development mode
|
||||
(i.e. `electron .`).
|
||||
|
||||
If you want to install the binary on demand instead, you can run the `install-electron` bin script
|
||||
included in the `electron` package:
|
||||
|
||||
```sh
|
||||
npx install-electron --no
|
||||
```
|
||||
|
||||
If you want to install your project's dependencies but don't need to use
|
||||
Electron functionality, you can set the `ELECTRON_SKIP_BINARY_DOWNLOAD` environment
|
||||
variable to prevent the binary from being downloaded. For instance, this feature can
|
||||
be useful in continuous integration environments when running unit tests that mock
|
||||
out the `electron` module.
|
||||
|
||||
```sh
|
||||
ELECTRON_SKIP_BINARY_DOWNLOAD=1 npm install
|
||||
```
|
||||
|
||||
## Running Electron ad-hoc
|
||||
|
||||
If you're in a pinch and would prefer to not use `npm install` in your local
|
||||
@@ -73,7 +49,7 @@ value, plus additional environment variables depending on your host system's Nod
|
||||
* [Node 10 and above][proxy-env-10]
|
||||
* [Before Node 10][proxy-env]
|
||||
|
||||
## Custom mirrors and caches
|
||||
## Custom Mirrors and Caches
|
||||
|
||||
During installation, the `electron` module will call out to
|
||||
[`@electron/get`][electron-get] to download prebuilt binaries of
|
||||
@@ -144,6 +120,23 @@ The cache contains the version's official zip file as well as a checksum, and is
|
||||
│ └── electron-v15.3.1-darwin-x64.zip
|
||||
```
|
||||
|
||||
## Postinstall script
|
||||
|
||||
Under the hood, Electron's JavaScript API binds to a binary that contains its
|
||||
implementations. Because this binary is crucial to the function of any Electron app,
|
||||
it is downloaded by default in the `postinstall` step every time you install `electron`
|
||||
from the npm registry.
|
||||
|
||||
However, if you want to install your project's dependencies but don't need to use
|
||||
Electron functionality, you can set the `ELECTRON_SKIP_BINARY_DOWNLOAD` environment
|
||||
variable to prevent the binary from being downloaded. For instance, this feature can
|
||||
be useful in continuous integration environments when running unit tests that mock
|
||||
out the `electron` module.
|
||||
|
||||
```sh npm2yarn
|
||||
ELECTRON_SKIP_BINARY_DOWNLOAD=1 npm install
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
When running `npm install electron`, some users occasionally encounter
|
||||
|
||||
@@ -171,7 +171,7 @@ sections.
|
||||
|
||||
In the main process, we'll be creating a `handleFileOpen()` function that calls
|
||||
`dialog.showOpenDialog` and returns the value of the file path selected by the user. This function
|
||||
is used as a callback whenever an `ipcRenderer.invoke` message is sent through the `dialog:openFile`
|
||||
is used as a callback whenever an `ipcRender.invoke` message is sent through the `dialog:openFile`
|
||||
channel from the renderer process. The return value is then returned as a Promise to the original
|
||||
`invoke` call.
|
||||
|
||||
@@ -446,7 +446,7 @@ After loading the preload script, your renderer process should have access to th
|
||||
We don't directly expose the whole `ipcRenderer.on` API for [security reasons][]. Make sure to
|
||||
limit the renderer's access to Electron APIs as much as possible.
|
||||
Also don't just pass the callback to `ipcRenderer.on` as this will leak `ipcRenderer` via `event.sender`.
|
||||
Use a custom handler that invokes the `callback` only with the desired arguments.
|
||||
Use a custom handler that invoke the `callback` only with the desired arguments.
|
||||
:::
|
||||
|
||||
:::info
|
||||
|
||||
@@ -10,7 +10,7 @@ hide_title: false
|
||||
## Accelerators
|
||||
|
||||
Accelerators are strings that can be used to represent keyboard shortcuts throughout your Electron.
|
||||
These strings can contain multiple modifier keys and a single key code joined by the `+` character.
|
||||
These strings can contain multiple modifiers keys and a single key code joined by the `+` character.
|
||||
|
||||
> [!NOTE]
|
||||
> Accelerators are **case-insensitive**.
|
||||
|
||||
@@ -62,9 +62,9 @@ const createWindow = () => {
|
||||
}
|
||||
```
|
||||
|
||||
In this next step, we will create our `BrowserWindow` and tell our application how to handle an event in which an external protocol is clicked.
|
||||
In this next step, we will create our `BrowserWindow` and tell our application how to handle an event in which an external protocol is clicked.
|
||||
|
||||
This code will be different in Windows and Linux compared to macOS. This is due to both platforms emitting the `second-instance` event rather than the `open-url` event and Windows requiring additional code in order to open the contents of the protocol link within the same Electron instance. Read more about this [here](../api/app.md#apprequestsingleinstancelockadditionaldata).
|
||||
This code will be different in Windows and Linux compared to MacOS. This is due to both platforms emitting the `second-instance` event rather than the `open-url` event and Windows requiring additional code in order to open the contents of the protocol link within the same Electron instance. Read more about this [here](../api/app.md#apprequestsingleinstancelockadditionaldata).
|
||||
|
||||
#### Windows and Linux code:
|
||||
|
||||
@@ -91,7 +91,7 @@ if (!gotTheLock) {
|
||||
}
|
||||
```
|
||||
|
||||
#### macOS code:
|
||||
#### MacOS code:
|
||||
|
||||
```js @ts-type={createWindow:()=>void}
|
||||
// This method will be called when Electron has finished
|
||||
|
||||
@@ -65,7 +65,7 @@ The full list of certificate types can be found
|
||||
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
|
||||
restriction, so apps signed with it can use either the normal build or the MAS
|
||||
restrictions, so apps signed with it can use either the normal build or the MAS
|
||||
build of Electron.
|
||||
|
||||
#### Legacy certificate names
|
||||
@@ -208,7 +208,7 @@ signAsync({
|
||||
After signing the app with the "Apple Distribution" certificate, you can
|
||||
continue to submit it to Mac App Store.
|
||||
|
||||
However, this guide does not ensure your app will be approved by Apple; you
|
||||
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.
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ Electron application, and this property only exists on macOS.
|
||||
One of the main uses for your app's Dock icon is to expose additional app menus. The Dock menu is
|
||||
triggered by right-clicking or <kbd>Ctrl</kbd>-clicking the app icon. By default, the app's Dock menu
|
||||
will come with system-provided window management utilities, including the ability to show all windows,
|
||||
hide the app, and switch between different open windows.
|
||||
hide the app, and switch betweeen different open windows.
|
||||
|
||||
To set an app-defined custom Dock menu, pass any [Menu](../api/menu.md) instance into the
|
||||
[`dock.setMenu`](../api/dock.md#docksetmenumenu-macos) API.
|
||||
|
||||
@@ -200,7 +200,7 @@ macOS has a number of platform-specific menu roles available. Many of these map
|
||||
|
||||
* `recentDocuments` - The submenu is an "Open Recent" menu.
|
||||
* `clearRecentDocuments` - Map to the [`clearRecentDocuments`](https://developer.apple.com/documentation/appkit/nsdocumentcontroller/clearrecentdocuments(_:)) action.
|
||||
* `shareMenu` - The submenu is [share menu](../api/share-menu.md). The `sharingItem` property must also be set to indicate the item to share.
|
||||
* `shareMenu` - The submenu is [share menu][ShareMenu]. The `sharingItem` property must also be set to indicate the item to share.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> When specifying a `role` on macOS, `label` and `accelerator` are the only
|
||||
|
||||
@@ -1339,7 +1339,7 @@ For developers wanting to learn more, you can refer to the [official N-API docum
|
||||
|
||||
### Putting `cpp_addon.cc` together
|
||||
|
||||
We've now finished the bridge part of our addon - that is, the code that's most concerned with being the bridge between your JavaScript and C++ code (and by contrast, less so actually interacting with the operating system or GTK). After adding all the sections above, your `src/cpp_addon.cc` should look like this:
|
||||
We've now finished the bridge part our addon - that is, the code that's most concerned with being the bridge between your JavaScript and C++ code (and by contrast, less so actually interacting with the operating system or GTK). After adding all the sections above, your `src/cpp_addon.cc` should look like this:
|
||||
|
||||
```cpp title='src/cpp_addon.cc'
|
||||
#include <napi.h>
|
||||
|
||||
@@ -4,13 +4,13 @@ This tutorial builds on the [general introduction to Native Code and Electron](.
|
||||
|
||||
Specifically, we'll be integrating with two commonly used native Windows libraries:
|
||||
|
||||
* `comctl32.lib`, which contains common controls and user interface components. It provides various UI elements like buttons, scrollbars, toolbars, status bars, progress bars, and tree views. As far as GUI development on Windows goes, this library is very low-level and basic - more modern frameworks like WinUI or WPF are more advanced alternatives but require a lot more C++ and Windows version considerations than are useful for this tutorial. This way, we can avoid the many perils of building native interfaces for multiple Windows versions!
|
||||
* `comctl32.lib`, which contains common controls and user interface components. It provides various UI elements like buttons, scrollbars, toolbars, status bars, progress bars, and tree views. As far as GUI development on Windows goes, this library is very low-level and basic - more modern frameworks like WinUI or WPF are advanced and alternatives but require a lot more C++ and Windows version considerations than are useful for this tutorial. This way, we can avoid the many perils of building native interfaces for multiple Windows versions!
|
||||
* `shcore.lib`, a library that provides high-DPI awareness functionality and other Shell-related features around managing displays and UI elements.
|
||||
|
||||
This tutorial will be most useful to those who already have some familiarity with native C++ GUI development on Windows. You should have experience with basic window classes and procedures, like `WNDCLASSEXW` and `WindowProc` functions. You should also be familiar with the Windows message loop, which is the heart of any native application - our code will be using `GetMessage`, `TranslateMessage`, and `DispatchMessage` to handle messages. Lastly, we'll be using (but not explaining) standard Win32 controls like `WC_EDITW` or `WC_BUTTONW`.
|
||||
|
||||
> [!NOTE]
|
||||
> If you're not familiar with C++ GUI development on Windows, we recommend Microsoft's excellent documentation and guides, particularly for beginners. "[Get Started with Win32 and C++](https://learn.microsoft.com/en-us/windows/win32/learnwin32/learn-to-program-for-windows)" is a great introduction.
|
||||
> If you're not familiar with C++ GUI development on Windows, we recommend Microsoft's excellent documentation and guides, particular for beginners. "[Get Started with Win32 and C++](https://learn.microsoft.com/en-us/windows/win32/learnwin32/learn-to-program-for-windows)" is a great introduction.
|
||||
|
||||
## Requirements
|
||||
|
||||
@@ -1333,7 +1333,7 @@ npm run build
|
||||
|
||||
## Conclusion
|
||||
|
||||
You've now built a complete native Node.js addon for Windows using C++ and the Win32 API. Some of the things we've done here are:
|
||||
You've now built a complete native Node.js addon for Windows using C++ and the Win32 API. Some of things we've done here are:
|
||||
|
||||
1. Creating a native Windows GUI from C++
|
||||
2. Implementing a Todo list application with Add, Edit, and Delete functionality
|
||||
|
||||
@@ -1167,7 +1167,7 @@ The approach demonstrated here allows you to:
|
||||
* Setting up bidirectional communication using callbacks and events
|
||||
* Configuring a custom build process to compile Swift code
|
||||
|
||||
For more information on developing with Swift and SwiftUI, refer to Apple's developer documentation:
|
||||
For more information on developing with Swift and Swift, refer to Apple's developer documentation:
|
||||
|
||||
* [Swift Programming Language](https://developer.apple.com/swift/)
|
||||
* [SwiftUI Framework](https://developer.apple.com/documentation/swiftui)
|
||||
|
||||
@@ -36,8 +36,8 @@ setting.
|
||||
This is an advanced feature requiring a native node module to work with your own code.
|
||||
The frames are directly copied in GPU textures, thus this mode is very fast because
|
||||
there's no CPU-GPU memory copies overhead, and you can directly import the shared
|
||||
texture to your own rendering program. You can read more details
|
||||
[here](../../shell/common/api/shared_texture/README.md).
|
||||
texture to your own rendering program. You can read more details at
|
||||
[here](https://github.com/electron/electron/blob/main/shell/browser/osr/README.md).
|
||||
|
||||
2. Use CPU shared memory bitmap
|
||||
|
||||
|
||||
@@ -294,7 +294,7 @@ particularly useful if users complain about your app sometimes "stuttering".
|
||||
|
||||
Generally speaking, all advice for building performant web apps for modern
|
||||
browsers apply to Electron's renderers, too. The two primary tools at your
|
||||
disposal are currently `requestIdleCallback()` for small operations and
|
||||
disposal are currently `requestIdleCallback()` for small operations and
|
||||
`Web Workers` for long-running operations.
|
||||
|
||||
_`requestIdleCallback()`_ allows developers to queue up a function to be
|
||||
@@ -360,7 +360,7 @@ turning into a desktop application. As web developers, we are used to loading
|
||||
resources from a variety of content delivery networks. Now that you are
|
||||
shipping a proper desktop application, attempt to "cut the cord" where possible
|
||||
and avoid letting your users wait for resources that never change and could
|
||||
easily be included in your app.
|
||||
easily be included in your app.
|
||||
|
||||
A typical example is Google Fonts. Many developers make use of Google's
|
||||
impressive collection of free fonts, which comes with a content delivery
|
||||
|
||||
@@ -113,7 +113,7 @@ For a full list of Electron's main process modules, check out our API documentat
|
||||
|
||||
Each Electron app spawns a separate renderer process for each open `BrowserWindow`
|
||||
(and each web embed). As its name implies, a renderer is responsible for
|
||||
_rendering_ web content. For all intents and purposes, code run in renderer processes
|
||||
_rendering_ web content. For all intents and purposes, code ran in renderer processes
|
||||
should behave according to web standards (insofar as Chromium does, at least).
|
||||
|
||||
Therefore, all user interfaces and app functionality within a single browser
|
||||
|
||||
@@ -9,7 +9,7 @@ toc_max_heading_level: 3
|
||||
|
||||
:::info Reporting security issues
|
||||
For information on how to properly disclose an Electron vulnerability,
|
||||
see [SECURITY.md](../../SECURITY.md).
|
||||
see [SECURITY.md](https://github.com/electron/electron/blob/main/SECURITY.md).
|
||||
|
||||
For upstream Chromium vulnerabilities: Electron keeps up to date with alternating
|
||||
Chromium releases. For more information, see the
|
||||
@@ -771,7 +771,7 @@ ipcMain.handle('get-secrets', (e) => {
|
||||
})
|
||||
|
||||
function validateSender (frame) {
|
||||
// Validate the host of the URL using an actual URL parser and an allowlist
|
||||
// Value the host of the URL using an actual URL parser and an allowlist
|
||||
if ((new URL(frame.url)).host === 'electronjs.org') return true
|
||||
return false
|
||||
}
|
||||
|
||||
@@ -2,4 +2,4 @@
|
||||
|
||||
* For information on supported releases, see the [Electron Releases](./electron-timelines.md) doc.
|
||||
* For community support on Electron, see the [Community page](https://www.electronjs.org/community).
|
||||
* For platform support info, see the [README](../../README.md).
|
||||
* For platform support info, see the [README](https://github.com/electron/electron/blob/main/README.md).
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
|
||||
Being based on Chromium, Electron requires a display driver to function.
|
||||
If Chromium can't find a display driver, Electron will fail to launch -
|
||||
and therefore not execute any of your tests, regardless of how you are running
|
||||
them. Testing Electron-based apps on Travis, CircleCI, Jenkins or similar systems
|
||||
and therefore not executing any of your tests, regardless of how you are running
|
||||
them. Testing Electron-based apps on Travis, CircleCI, Jenkins or similar Systems
|
||||
requires therefore a little bit of configuration. In essence, we need to use
|
||||
a virtual display driver.
|
||||
|
||||
|
||||
@@ -44,7 +44,7 @@ following JSON format:
|
||||
"updateTo": {
|
||||
"version": "1.2.1",
|
||||
"pub_date": "2023-09-18T12:29:53+01:00",
|
||||
"notes": "These are some release notes innit",
|
||||
"notes": "Theses are some release notes innit",
|
||||
"name": "1.2.1",
|
||||
"url": "https://mycompany.example.com/myapp/releases/myrelease"
|
||||
}
|
||||
@@ -54,7 +54,7 @@ following JSON format:
|
||||
"updateTo": {
|
||||
"version": "1.2.3",
|
||||
"pub_date": "2024-09-18T12:29:53+01:00",
|
||||
"notes": "These are some more release notes innit",
|
||||
"notes": "Theses are some more release notes innit",
|
||||
"name": "1.2.3",
|
||||
"url": "https://mycompany.example.com/myapp/releases/myrelease3"
|
||||
}
|
||||
@@ -307,7 +307,7 @@ app update. All other properties in the object are optional.
|
||||
{
|
||||
"url": "https://your-static.storage/your-app-1.2.3-darwin.zip",
|
||||
"name": "1.2.3",
|
||||
"notes": "These are some release notes innit",
|
||||
"notes": "Theses are some release notes innit",
|
||||
"pub_date": "2024-09-18T12:29:53+01:00"
|
||||
}
|
||||
```
|
||||
|
||||
@@ -149,7 +149,7 @@ 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 the `prebuild`-powered module provides binaries for the usage in Electron,
|
||||
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.
|
||||
|
||||
|
||||
@@ -38,7 +38,7 @@ To test your app, use a Windows on Arm device running Windows 10 (version 1903 o
|
||||
|
||||
### Node.js/node-gyp
|
||||
|
||||
[Node.js v12.9.0 or later is recommended.](https://nodejs.org/en/) If updating to a new version of Node is undesirable, you can instead [update npm's copy of node-gyp manually](https://github.com/nodejs/node-gyp/wiki/Updating-npm's-bundled-node-gyp) to version 5.0.2 or later, which contains the required changes to compile native modules for Arm.
|
||||
[Node.js v12.9.0 or later is recommended.](https://nodejs.org/en/) If updating to a new version of Node is undesirable, you can instead [update npm's copy of node-gyp manually](https://github.com/nodejs/node-gyp/wiki/Updating-npm's-bundled-node-gyp) to version 5.0.2 or later, which contains the required changes to compile native modules for Arm.
|
||||
|
||||
### Visual Studio 2017
|
||||
|
||||
|
||||
@@ -134,7 +134,7 @@ system.
|
||||
|
||||
Before running the CLI for the first time, you will have to setup the "Windows Desktop App
|
||||
Converter". This will take a few minutes, but don't worry - you only have to do
|
||||
this once. Download the Desktop App Converter from [here][app-converter].
|
||||
this once. Download and Desktop App Converter from [here][app-converter].
|
||||
You will receive two files: `DesktopAppConverter.zip` and `BaseImage-14316.wim`.
|
||||
|
||||
1. Unzip `DesktopAppConverter.zip`. From an elevated PowerShell (opened with
|
||||
|
||||
@@ -30,7 +30,7 @@ If you want to focus on building a great product without debugging a weird quirk
|
||||
|
||||
Whatever provider or customer data you need to interact with, they will have probably thought of an integration path with the web. Depending on your technology choice, embedding a YouTube video either takes 30 seconds or requires you to hire a team devoted to streaming and hardware-accelerated video decoding. In the case of YouTube, using anything other than the provided players is actually against their terms and conditions, so you’ll likely embed a browser frame before you implement your own video streaming decoder.
|
||||
|
||||
There will be virtually no platform where your app cannot run if you build it with web technologies. Virtually all devices with a display—be that an ATM, a car infotainment system, a smart TV, a fridge, or a Nintendo Switch—come with means to display web technologies. The web is a safe bet if you want to be cross-platform.
|
||||
There will be virtually no platform where your app cannot run if you build it with web technologies. Virtually all devices with a display—be that an ATM, a car infotainment system, a smart TV, a fridge, or a Nintendo Switch—come with means to display web technologies. The web is safe bet if you want to be cross-platform.
|
||||
|
||||
### Ubiquity
|
||||
|
||||
@@ -59,7 +59,7 @@ What does all of that mean for you, a developer, in practice?
|
||||
|
||||
### Stability, security, performance
|
||||
|
||||
Electron delivers the best experience on all target platforms (macOS, Windows, Linux) by bundling the latest version of Chromium, V8, and Node.js directly with the application binary. When it comes to running and rendering web content with utmost stability, security, and performance, we currently believe that stack to be “best in class”.
|
||||
Electron delivers the best experience on all target platforms (macOS, Windows, Linux) by bundling the latest version of Chromium, V8, and Node.js directly with the application binary. When it comes to running and rendering web content with upmost stability, security, and performance, we currently believe that stack to be “best in class”.
|
||||
|
||||
#### Why bundle anything at all
|
||||
|
||||
|
||||
@@ -50,8 +50,6 @@ filenames = {
|
||||
"shell/browser/ui/views/caption_button_placeholder_container.h",
|
||||
"shell/browser/ui/views/client_frame_view_linux.cc",
|
||||
"shell/browser/ui/views/client_frame_view_linux.h",
|
||||
"shell/browser/ui/views/linux_frame_layout.cc",
|
||||
"shell/browser/ui/views/linux_frame_layout.h",
|
||||
"shell/common/application_info_linux.cc",
|
||||
"shell/common/language_util_linux.cc",
|
||||
"shell/common/node_bindings_linux.cc",
|
||||
@@ -81,8 +79,6 @@ filenames = {
|
||||
"shell/browser/notifications/win/notification_presenter_win.h",
|
||||
"shell/browser/notifications/win/windows_toast_notification.cc",
|
||||
"shell/browser/notifications/win/windows_toast_notification.h",
|
||||
"shell/browser/notifications/win/windows_toast_activator.cc",
|
||||
"shell/browser/notifications/win/windows_toast_activator.h",
|
||||
"shell/browser/relauncher_win.cc",
|
||||
"shell/browser/ui/certificate_trust_win.cc",
|
||||
"shell/browser/ui/file_dialog_win.cc",
|
||||
@@ -301,7 +297,6 @@ filenames = {
|
||||
"shell/browser/api/electron_api_push_notifications.cc",
|
||||
"shell/browser/api/electron_api_push_notifications.h",
|
||||
"shell/browser/api/electron_api_safe_storage.cc",
|
||||
"shell/browser/api/electron_api_safe_storage.h",
|
||||
"shell/browser/api/electron_api_screen.cc",
|
||||
"shell/browser/api/electron_api_screen.h",
|
||||
"shell/browser/api/electron_api_service_worker_context.cc",
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
const { safeStorage } = process._linkedBinding('electron_browser_safe_storage');
|
||||
const safeStorage = process._linkedBinding('electron_browser_safe_storage');
|
||||
|
||||
export default safeStorage;
|
||||
module.exports = safeStorage;
|
||||
|
||||
@@ -263,12 +263,7 @@ WebContents.prototype.print = function (options: ElectronInternal.WebContentsPri
|
||||
throw new TypeError('webContents.print(): Invalid print settings specified.');
|
||||
}
|
||||
|
||||
const { pageSize, usePrinterDefaultPageSize } = options;
|
||||
|
||||
if (usePrinterDefaultPageSize !== undefined && pageSize !== undefined) {
|
||||
throw new Error('usePrinterDefaultPageSize cannot be combined with pageSize');
|
||||
}
|
||||
|
||||
const { pageSize } = options;
|
||||
if (typeof pageSize === 'string' && PDFPageSizes[pageSize]) {
|
||||
const mediaSize = PDFPageSizes[pageSize];
|
||||
options.mediaSize = {
|
||||
|
||||
35
npm/index.js
35
npm/index.js
@@ -1,27 +1,8 @@
|
||||
const { spawnSync } = require('child_process');
|
||||
const fs = require('fs');
|
||||
const path = require('path');
|
||||
|
||||
const pathFile = path.join(__dirname, 'path.txt');
|
||||
|
||||
function downloadElectron () {
|
||||
console.log('Downloading Electron binary...');
|
||||
const result = spawnSync(process.execPath, [path.join(__dirname, 'install.js')], {
|
||||
stdio: 'inherit'
|
||||
});
|
||||
if (result.status !== 0) {
|
||||
throw new Error(
|
||||
'Electron failed to install correctly. Please delete `node_modules/electron` and run "npx install-electron --no" manually.'
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Fetches the path to the Electron executable to use in development mode.
|
||||
* If the executable is missing, attempt to download it first.
|
||||
*
|
||||
* @returns the path to the Electron executable to run
|
||||
*/
|
||||
function getElectronPath () {
|
||||
let executablePath;
|
||||
if (fs.existsSync(pathFile)) {
|
||||
@@ -31,21 +12,9 @@ function getElectronPath () {
|
||||
return path.join(process.env.ELECTRON_OVERRIDE_DIST_PATH, executablePath || 'electron');
|
||||
}
|
||||
if (executablePath) {
|
||||
const fullPath = path.join(__dirname, 'dist', executablePath);
|
||||
if (!fs.existsSync(fullPath)) {
|
||||
downloadElectron();
|
||||
}
|
||||
return fullPath;
|
||||
} else {
|
||||
try {
|
||||
downloadElectron();
|
||||
} catch {
|
||||
throw new Error(
|
||||
'Electron failed to install correctly. Please delete `node_modules/electron` and run "npx install-electron --no" manually.'
|
||||
);
|
||||
}
|
||||
executablePath = fs.readFileSync(pathFile, 'utf-8');
|
||||
return path.join(__dirname, 'dist', executablePath);
|
||||
} else {
|
||||
throw new Error('Electron failed to install correctly, please delete node_modules/electron and try installing again');
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@@ -2,8 +2,10 @@
|
||||
"main": "index.js",
|
||||
"types": "electron.d.ts",
|
||||
"bin": {
|
||||
"electron": "cli.js",
|
||||
"install-electron": "install.js"
|
||||
"electron": "cli.js"
|
||||
},
|
||||
"scripts": {
|
||||
"postinstall": "node install.js"
|
||||
},
|
||||
"dependencies": {
|
||||
"@electron/get": "^2.0.0",
|
||||
|
||||
12
package.json
12
package.json
@@ -12,7 +12,6 @@
|
||||
"@electron/github-app-auth": "^3.2.0",
|
||||
"@electron/lint-roller": "^3.2.0",
|
||||
"@electron/typescript-definitions": "^9.1.5",
|
||||
"@hurdlegroup/robotjs": "^0.12.3",
|
||||
"@octokit/rest": "^20.1.2",
|
||||
"@primer/octicons": "^10.0.0",
|
||||
"@types/minimist": "^1.2.5",
|
||||
@@ -56,7 +55,7 @@
|
||||
"ts-node": "6.2.0",
|
||||
"typescript": "^5.8.3",
|
||||
"url": "^0.11.4",
|
||||
"webpack": "^5.104.1",
|
||||
"webpack": "^5.95.0",
|
||||
"webpack-cli": "^6.0.1",
|
||||
"wrapper-webpack-plugin": "^2.2.0",
|
||||
"yaml": "^2.8.1"
|
||||
@@ -64,8 +63,9 @@
|
||||
"private": true,
|
||||
"scripts": {
|
||||
"asar": "asar",
|
||||
"check-signed-commits": "node ./script/check-signed-commits.js",
|
||||
"generate-version-json": "node script/generate-version-json.js",
|
||||
"lint": "node ./script/lint.js && npm run lint:docs && npm run lint:chromium-roller",
|
||||
"lint": "node ./script/lint.js && npm run lint:docs",
|
||||
"lint:js": "node ./script/lint.js --js",
|
||||
"lint:clang-format": "python3 script/run-clang-format.py -r -c shell/ || (echo \"\\nCode not formatted correctly.\" && exit 1)",
|
||||
"lint:clang-tidy": "ts-node ./script/run-clang-tidy.ts",
|
||||
@@ -75,12 +75,11 @@
|
||||
"lint:gn": "node ./script/lint.js --gn",
|
||||
"lint:docs": "remark docs -qf && npm run lint:js-in-markdown && npm run create-typescript-definitions && npm run lint:ts-check-js-in-markdown && npm run lint:docs-fiddles && npm run lint:docs-relative-links && npm run lint:markdown && npm run lint:api-history",
|
||||
"lint:docs-fiddles": "standard \"docs/fiddles/**/*.js\"",
|
||||
"lint:docs-relative-links": "lint-roller-markdown-links --resource-root . --root docs \"**/*.md\"",
|
||||
"lint:docs-relative-links": "lint-roller-markdown-links --root docs \"**/*.md\"",
|
||||
"lint:markdown": "node ./script/lint.js --md",
|
||||
"lint:ts-check-js-in-markdown": "lint-roller-markdown-ts-check --root docs \"**/*.md\" --ignore \"breaking-changes.md\"",
|
||||
"lint:js-in-markdown": "lint-roller-markdown-standard --root docs \"**/*.md\"",
|
||||
"lint:api-history": "lint-roller-markdown-api-history --root \"./docs/api/\" --schema \"./docs/api-history.schema.json\" --breaking-changes-file \"./docs/breaking-changes.md\" --check-placement --check-strings \"*.md\"",
|
||||
"lint:chromium-roller": "node ./script/lint-roller-chromium-changes.mjs",
|
||||
"create-api-json": "node script/create-api-json.mjs",
|
||||
"create-typescript-definitions": "npm run create-api-json && electron-typescript-definitions --api=electron-api.json && node spec/ts-smoke/runner.js",
|
||||
"gn-typescript-definitions": "npm run create-typescript-definitions && node script/cp.mjs electron.d.ts",
|
||||
@@ -104,9 +103,6 @@
|
||||
"electron"
|
||||
],
|
||||
"lint-staged": {
|
||||
"*": [
|
||||
"npm run lint:chromium-roller"
|
||||
],
|
||||
"*.{js,ts}": [
|
||||
"node script/lint.js --js --fix --only --"
|
||||
],
|
||||
|
||||
@@ -82,7 +82,7 @@ index feaf17c72cecb8099bc11ac10747fbad719ddca9..891a73f229e3f0838cb2fa99b8fb24fd
|
||||
|
||||
void EVP_MD_do_all(void (*callback)(const EVP_MD *cipher, const char *name,
|
||||
diff --git a/include/openssl/digest.h b/include/openssl/digest.h
|
||||
index 40670234682ac00dec268dea43f0ee1e39e8684f..293fbc9faf01ea0ca4e58b0a65b14597fe4916a6 100644
|
||||
index a86c18926e7798a3b0aae70c53870e03b5acd0ab..f4f27f9e803533d8db50d89e7a0125384a025a46 100644
|
||||
--- a/include/openssl/digest.h
|
||||
+++ b/include/openssl/digest.h
|
||||
@@ -48,6 +48,9 @@ OPENSSL_EXPORT const EVP_MD *EVP_blake2b256(void);
|
||||
|
||||
@@ -142,5 +142,6 @@ chore_disable_protocol_handler_dcheck.patch
|
||||
fix_check_for_file_existence_before_setting_mtime.patch
|
||||
fix_linux_tray_id.patch
|
||||
expose_gtk_ui_platform_field.patch
|
||||
fix_os_crypt_async_cookie_encryption.patch
|
||||
patch_osr_control_screen_info.patch
|
||||
refactor_allow_customizing_config_in_freedesktopsecretkeyprovider.patch
|
||||
graphite_handle_out_of_order_recording_errors.patch
|
||||
|
||||
@@ -10,7 +10,7 @@ Allows Electron to restore WER when ELECTRON_DEFAULT_ERROR_MODE is set.
|
||||
This should be upstreamed.
|
||||
|
||||
diff --git a/content/gpu/gpu_main.cc b/content/gpu/gpu_main.cc
|
||||
index 7265019647734154f64108efd7e6376b7a9fc1ba..398aaff3af5bff791f114e4023d0e07be86dd79a 100644
|
||||
index 30cc1d4a179f9da59824cb98415baed8493fc843..2272eaa7e0e3306201e5e32226a0115f6f6636e5 100644
|
||||
--- a/content/gpu/gpu_main.cc
|
||||
+++ b/content/gpu/gpu_main.cc
|
||||
@@ -272,6 +272,10 @@ int GpuMain(MainFunctionParams parameters) {
|
||||
@@ -24,7 +24,7 @@ index 7265019647734154f64108efd7e6376b7a9fc1ba..398aaff3af5bff791f114e4023d0e07b
|
||||
// We are experiencing what appear to be memory-stomp issues in the GPU
|
||||
// process. These issues seem to be impacting the task executor and listeners
|
||||
// registered to it. Create the task executor on the heap to guard against
|
||||
@@ -380,7 +384,6 @@ int GpuMain(MainFunctionParams parameters) {
|
||||
@@ -381,7 +385,6 @@ int GpuMain(MainFunctionParams parameters) {
|
||||
#endif
|
||||
const bool dead_on_arrival = !init_success;
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user