* refactor: simplify Invoker::IsOK()
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* refactor: might as well make it [[nodiscard]] as well
Co-authored-by: Charles Kerr <charles@charleskerr.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
refactor: remove unused isolate arg from GlobalShortcut constructor
has not been used since f1a0d5e811 (#22755)
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
refactor: do not use AdaptCallbackForRepeating in electron_api_url_loader.cc
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* chore: bump chromium in DEPS to 134.0.6998.3
* chore: bump chromium in DEPS to 134.0.6998.15
* chore: bump chromium in DEPS to 134.0.6998.23
---------
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
refactor: use base::FindPtrOrNull() in WebFrameMain::FromFrameTreeNodeId()
refactor: use base::FindPtrOrNull() in WebFrameMain::FromFrameToken()
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
refactor: use C++20's contains() method (#45742)
* chore: use std::map<>::contains() instead of count() or find()
* chore: use std::map<>::contains() instead of base::Contains()
refactor: use base::as_bytes() in WriteAsciiChunk()
this avoids a reinterpret_cast and a static_cast
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* fix: crash parsing CLSID in shell.readShortcutLink
Co-authored-by: David Lönnhager <david.l@mullvad.net>
* fix: ignore clsid if it could not be set
Co-authored-by: David Lönnhager <david.l@mullvad.net>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: David Lönnhager <david.l@mullvad.net>
This fixture has been calling process.exit() immediately after writing
to stdout and stderr, which the Node.js docs say is risky behavior:
> Calling process.exit() will force the process to exit as quickly as
> possible even if there are still asynchronous operations pending that
> have not yet completed fully, including I/O operations to
> process.stdout and process.stderr.
This fixture's been around for years without problems (AFAIK).
The writes are very small ('hello\n' and 'world') and finish quickly.
But recently I've been testing on a very slow CI machine. There, I see
this spec flaking when it expects stderr to be 'world' but it gets ''.
This PR changes the fixture to wait for stdout & stderr to flush
before calling process.exit().
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* fix: close quick look during tests on macOS
Co-authored-by: Samuel Maddock <smaddock@slack-corp.com>
* use longer delay 🤷
Co-authored-by: Samuel Maddock <smaddock@slack-corp.com>
* fix: sharedPreviewPanel being recreated on close
Co-authored-by: Samuel Maddock <smaddock@slack-corp.com>
* test: ensure preview panel gets closed
Co-authored-by: Samuel Maddock <smaddock@slack-corp.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Samuel Maddock <smaddock@slack-corp.com>
* feat: Working navigationHistory.restore with just title/url
Co-authored-by: Felix Rieseberg <fr@makenotion.com>
* feat: Restore page state, too
Co-authored-by: Felix Rieseberg <fr@makenotion.com>
* chore: Docs, lint, tests
Co-authored-by: Felix Rieseberg <fr@makenotion.com>
* Implement feedback
Co-authored-by: Felix Rieseberg <fr@makenotion.com>
* More magic
Co-authored-by: Felix Rieseberg <fr@makenotion.com>
* Make _awaitNextLoad truly private
Co-authored-by: Felix Rieseberg <fr@makenotion.com>
* Implement API group feedback
Co-authored-by: Felix Rieseberg <fr@makenotion.com>
* One more round of feedback
Co-authored-by: Felix Rieseberg <fr@makenotion.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Felix Rieseberg <fr@makenotion.com>
- Prefer GURL() when we want to return a non-reference empty URL.
- In ServiceWorkerMain::GetStorageKey(), use a reference instead
of instantiating a new temporary GURL.
From url/gurl.h:
> // Returns a reference to a singleton empty GURL. This object is for
> // callers who return references but don't have anything to return in
> // some cases. If you just want an empty URL for normal use, prefer
> // GURL().
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* test: disable unexpectedly quit dialog on macOS
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* test: take screenshot before keyboard lock test
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* Revert "test: take screenshot before keyboard lock test"
This reverts commit 3ba5c6984f.
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* chore: bump chromium to 134.0.6989.0
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* chore: update patches/chromium/cherry-pick-dd8e2822e507.patch
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* chore: e patches all
Co-authored-by: Charles Kerr <charles@charleskerr.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
refactor: forward v8::Context to v8::MicrotasksScope constructor
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Milan Burda <milan.burda@gmail.com>
When using `views::WebView` on macOS `NativeWidgetMacNSWindowHost`
contains a layer and compositor responsible for drawing web contents.
To trigger drawing `NativeWidgetMacNSWindowHost::OnVisibilityChanged`
needs to be called and `[NSWindow orderFrontRegardless]` does not trigger
`[NSWindow orderWindow:relativeTo:]` which can change
`NativeWidgetMacNSWindowHost` visiblity with stack:
```
views::NativeWidgetMacNSWindowHost::OnVisibilityChanged(bool)
remote_cocoa::NativeWidgetNSWindowBridge::OnVisibilityChanged()
-[ViewsNSWindowDelegate onWindowOrderChanged:]
-[NativeWidgetMacNSWindow orderWindow:relativeTo:]
```
`views::Widget` has method for showing inactive window:
`views::Widget::ShowInactive` which triggers
`NativeWidgetMacNSWindowHost::OnVisibilityChanged` with stack:
```
views::NativeWidgetMacNSWindowHost::OnVisibilityChanged(bool)
remote_cocoa::NativeWidgetNSWindowBridge::SetVisibilityState(remote_cocoa::mojom::WindowVisibilityState)
views::NativeWidgetMacNSWindowHost::SetVisibilityState(remote_cocoa::mojom::WindowVisibilityState)
views::NativeWidgetMac::Show(ui::mojom::WindowShowState, gfx::Rect const&)
views::Widget::ShowInactive() + 168
```
However this call seems to be insufficient to bring window to front,
therefore `[NSWindow orderFrontRegardless]` still needs to be called.
Calling `views::Widget::ShowInactive` ensures that all logic related to
showing Chromium widget will be properly executed, but onfortunately it
does not call `[NSWindow orderWindow:relativeTo:]` which is used to
disabling headless mode by the `ElectronNSWindow`, therefore we need to
trigger it manually through exposed `[ElectronNSWindow disableHeadlessMode]`.
Fixes: #45415
Co-authored-by: Michał Pichliński <michal.pichlinski@here.io>
build: always use python3 in script/lib/get-version.js
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: David Sanders <dsanders11@ucsbalum.com>
feat: service worker preload scripts for improved extensions support (#44411)
* feat: preload scripts for service workers
* feat: service worker IPC
* test: service worker preload scripts and ipc
* chore: bump chromium in DEPS to 133.0.6943.16
* chore: bump chromium in DEPS to 133.0.6943.27
* chore: bump chromium in DEPS to 133.0.6943.35
* chore: bump chromium to 134.0.6968.0
cherry picked from 75eac86506
---------
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
build: add NSPrefersDisplaySafeAreaCompatibilityMode = false to Info.plist
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Milan Burda <milan.burda@gmail.com>
* docs: Add note about directly exposing Electron APIs in preload
Co-authored-by: Felix Rieseberg <fr@makenotion.com>
* Implement feedback
Co-authored-by: Felix Rieseberg <fr@makenotion.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Felix Rieseberg <fr@makenotion.com>
* refactor: remove InspectableWebContentsViewMac in favor of the Views version
* cherry-pick: refactor: remove InspectableWebContentsViewMac in favor of the Views version (#41326)
commit e67ab9a93d
Confilcts not resolved, except removal of the files removed
by the original commit.
* resolved conflicts and build issues after cherry-pick
* cherry-picked: fix: add method allowing to disable headless mode in native widget
https://github.com/electron/electron/pull/42996
fixing
https://github.com/electron/electron/issues/42995
* fix: displaying select popup in window created as fullscreen window
`constrainFrameRect:toScreen:` is not being call for windows created
with `fullscreen: true` therefore `headless` mode was not being removed
and `RenderWidgetHostNSViewBridge::DisplayPopupMenu` ignored displaying
popup.
Issue could be fixed by placing additional removal of `headless` mode
in the `toggleFullScreen:`, but `orderWindow:relativeTo:` is called
both for a regular and a fullscreen window, therefore there will be
a single place fixing both cases.
Because `electron::NativeWindowMac` lifetime may be shorter than
`ElectronNSWindow` on which macOS may execute `orderWindow:relativeTo:`
we need to clear `shell_` when `NativeWindow` is being closed.
Fixes#43010.
* fix: Content visibility when using `vibrancy`
We need to put `NSVisualEffectView` before `ViewsCompositorSuperview`
otherwise when using `vibrancy` in `BrowserWindow` `NSVisualEffectView`
will hide content displayed by the compositor.
Fixes#43003Fixes#42336
In fact main issues reported in these tickets were not present after
cherry-picking original refactor switching to `views::WebView`, so
text could be selected and click event was properly generated. However
both issues testcases were using `vibrancy` and actual content was
invisible, because it was covered by the `NSVisualEffectView`.
* fix: EXCEPTION_ACCESS_VIOLATION crash on BrowserWindow.destroy()
Restored postponed deletion of the `NativeWindow`.
Restoration caused `DCHECK(new_parent_ui_layer->GetCompositor());` failure
in `BrowserCompositorMac::SetParentUiLayer` after the spec test:
`chrome extensions chrome.webRequest does not take precedence over Electron webRequest - http`
with stack:
```
7 Electron Framework 0x000000011fe07830 content::BrowserCompositorMac::SetParentUiLayer(ui::Layer*) + 628
8 Electron Framework 0x000000011fe0c154 content::RenderWidgetHostViewMac::SetParentUiLayer(ui::Layer*) + 220
9 Electron Framework 0x000000011fe226a8 content::WebContentsViewMac::CreateViewForWidget(content::RenderWidgetHost*) + 600
10 Electron Framework 0x000000011fd37e4c content::WebContentsImpl::CreateRenderWidgetHostViewForRenderManager(content::RenderViewHost*) + 164
11 Electron Framework 0x000000011fb32278 content::RenderFrameHostManager::CreateSpeculativeRenderFrame(content::SiteInstanceImpl*, bool, scoped_refptr<content::BrowsingContextState> const&) + 816
12 Electron Framework 0x000000011fb2ab8c content::RenderFrameHostManager::CreateSpeculativeRenderFrameHost(content::SiteInstanceImpl*, content::SiteInstanceImpl*, bool) + 1308
13 Electron Framework 0x000000011fb28598 content::RenderFrameHostManager::GetFrameHostForNavigation(content::NavigationRequest*, content::BrowsingContextGroupSwap*, std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char>>*) + 1796
14 Electron Framework 0x000000011fa78660 content::NavigationRequest::SelectFrameHostForOnRequestFailedInternal(bool, bool, std::__Cr::optional<std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char>>> const&) + 280
15 Electron Framework 0x000000011fa6a994 content::NavigationRequest::OnRequestFailedInternal(network::URLLoaderCompletionStatus const&, bool, std::__Cr::optional<std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char>>> const&, bo
+ 1008
16 Electron Framework 0x000000011fa7772c content::NavigationRequest::OnRequestFailed(network::URLLoaderCompletionStatus const&) + 72
17 Electron Framework 0x000000011f8554ac content::NavigationURLLoaderImpl::NotifyRequestFailed(network::URLLoaderCompletionStatus const&) + 248
```
This was probably the reason of removing `NativeWindow` immediately
in order to cleanup `views_host_` in `WebContentsViewMac` to prevent
using layer without compositor in `WebContentsViewMac::CreateViewForWidget`.
`[ElectronNSWindowDelegate windowWillClose:]` is deleting window host
and the compositor used by the `NativeWindow` therefore detach `NativeWindow`
contents from parent. This will clear `views_host_` and prevent failing
mentioned `DCHECK`.
Fixes#42975
* chore: Applied review suggestions
Co-authored-by: Michał Pichliński <michal.pichlinski@here.io>
* refactor: directly cleanup shell
Co-authored-by: Samuel Maddock <smaddock@slack-corp.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Michał Pichliński <michal.pichlinski@here.io>
Co-authored-by: Samuel Maddock <smaddock@slack-corp.com>
refactor: simplify StopTracing() a little by using a string_view instead of an optional<string>
We have compile-time string literals that we're passing to a method
that takes a string_view argument, so we don't need all this extra
optional<string> scaffolding
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
refactor: simplify ParseUserScript()
local variable user_script no longer needed after #43205
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
In the old version of get-version.js, it replaces the leading 'v',
i.e. |output.stdout.toString().trim().replace(/^v/g, '')|. However,
in the new version of get-git-version.py, it directly replaces all
'v'. Obviously, it does not conform to the original semantics.
Although it will not affect the existing electron version calculation,
it may affect other developers' customized git-tag-version, such as
v0.0.0-dev.xxx, which will lose the 'v' of dev.
* fix: add patch to fix desktopCapturer.getSources not returning electron window on Windows
* add chromium link
* Update patches/chromium/fix_desktop_capturer_show_own_window.patch
Co-authored-by: Keeley Hammond <vertedinde@electronjs.org>
* fix on electron side
* set flag to true
* wrong capturer
---------
Co-authored-by: Keeley Hammond <vertedinde@electronjs.org>
Update window-setup.ts
The message should simply read "is not supported" or, alternatively, "is not, and will not, be supported", but not "is and will not be supported".
`ReadUnicodeCharacter` updates index to the last character read, and not after it. We need to manually increment it to move to the next character.
It also doesn't validate that the index is valid, so we need to check that index is within bounds.
Refs: #44336
* build: test windows runner
* build: try build windows on windows?
* build: take win/cross changes
* build: use bash as default shell always
* build: configure git for windows build tools
* build: bash as default
* build: configure windows correctly
* build: use sha1sum
* build: force windows cipd init and python3 existence
* just pain
* build: restore cache on windows
* build: use build-tools gclient
* build: sync gclient vars to build windows job
* build: output depshash for debugging
* build: past sam was a silly goose
* build: depshash logging
* build: force lf endings for lock and DEPS
* build: platform strings are hard
* build: checkout on windows host
* sup
* no check
* idk
* sigh
* ...
* no double checkout
* build: yolo some stuff
* build: run gn-check for windows on linux hosts for speed
* use container...
* cry ?
* build: e d
* e d
* no log
* fix toolchain on windows cross check
* build: use powershell to add mksnapshot_args
* build: enable x86 and arm64 windows builds too
* clean up
* maybe not needed
* build: keep action around for post step
* build: configure git global on win
* build: ia32 zip manifest
* build: no patch depot_tools for tests
* build: get arm64 windows closer to working
* build: windows tar is ass
* 32 bit on 32 bit
* maybe bash
* build: set up nodejs
* correct windows sharding
* fix some spec runner stuff
* fix windows tests
* overwrite -Force
* sigh
* screen res
* wat
* logs
* ... more logs
* line endings will be the death of me
* remove 1080p force thing
* vsctools + logging
* disable some fullscreen tests on GHA
* no progress
* run all CI
* install visual studio on arm64
* windows hax for non windows
* maybe arm sdk
* clean up depshash logic
* build: use single check per platform
* ensure clean args
* fix loop
* remove debug
* update default build image sha for dispatch
* plzzzz
* one more try
* arm64 vctools
* sad
* build: fix non-dispatch windows gn check
* chore: debug datadog-ci location
* chore: update build-tools for newer toolchain
* chore: set path for datadog-ci
* try this
* chore: fixup gn check
* fixup gn-check some more
* fixup windows gn check
* chore: fixup windows gn check
* test: use cmd for Windows testing
* fixup use cmd for testing on Windows
* fixup windows GN check
* fixup npm config arch for x86
* Can we set test files via powershell
* fixup to set test files via powershell
* fixup set test files via powershell
* Don't check cross instance cache disk space on Windows
* Use separate step to set env variables for testing
* fixup Use separate step to set env variables for testing
* fixup Use separate step to set env variables for testing
* fixup Use separate step to set env variables for testing (AGAIN)
* use powershell if in powershell
* fixup use powershell if in powershell
* chore: remove no longer needed changes to depot_tools
xref: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/5669094
and https://chromium-review.googlesource.com/c/chromium/src/+/5844046
* chore: try using 7zip on Windows to extract tarball
* Revert "chore: try using 7zip on Windows to extract tarball"
This reverts commit c7432b6a37.
* test: debug failing tests on GHA windows
* fix: ftbfs when including simdjson in Node.js
(cherry picked from commit 48e44c40d6)
* chore: try to track down Windows testing hang
* use correct timeout
* try this
* see if this helps
* try to figure out why node is running
* shard tests to try to narrow down WOA lockup
* try to narrow down problem test
* Narrow down blocking test more
* do we need a combo to repro
* see if this cleans up the tests
* fixup navigator.usb test
* remove logging from problematic tests
* Revert "shard tests to try to narrow down WOA lockup"
This reverts commit a180658376.
* remove logging
* debug keyboard test
* add timeout for Windows since arm64 sometimes hangs
* see if this helps
* put back original timeout
* try to use screenCapture to get screenshots of what is going on on WOA
* try using electron screencapture to debug WOA hang
* chore: turn off privacy experience
* run screenshot on both shards
* fixup screencap
* try to narrow down hanging spec
* chore: cleanup servers left open
* cleanup tests
* Revert "try to narrow down hanging spec"
This reverts commit a0f959f538.
* cleanup test debugging
* fixup extensions spec
* cleanup unneeded items
* run wtf with 2 shards instead of 6
* Revert "run wtf with 2 shards instead of 6"
This reverts commit ca2d282129.
* debug windows version on woa
* dump more info
* Get detailed CPU info
* revert debugging
* use same args as AppVeyor WOA for GHA WOA
* fixup use same args as AppVeyor WOA for GHA WOA
* fixup use same args as AppVeyor WOA for GHA WOA
* try to track down which tests trigger hang
* one or more of these combinations should hang
* break up web contents spec to find hang
* further break down api-web-contents to find hang
* test: ensure all webContents are closed
* test: fix require is not defined error
* see if api-web-contents spec is now good
* test: ensure all webContents are closed
* Revert "try to track down which tests trigger hang"
This reverts commit 07298d6ffe.
* chore: use alternate location for windows toolchain
* Reapply "try to track down which tests trigger hang"
This reverts commit 0321f76d01.
* try to narrow down problem test
* fix TEST_SHARD env var
* no, really fix TEST_SHARD env var
* see if this fixes it
* test: cleanup any remaining windows and webcontents
* see if new cleanup helps
* dont destroy webcontents for now
* fixup dont destroy webcontents for now
* Only cleanup right before process.exit
* see if this fixes the hang
* actually destroy webcontents
* Revert "Reapply "try to track down which tests trigger hang""
This reverts commit cdee7de049.
* see if this helps
* Revert "see if this helps"
This reverts commit 9a15a69cf7.
* Is it all about the web contents?
* it is all about the webcontents
but which one?
* Narrow down problem webcontents test
* try to speed up git install on WOA
* disable problematic test on WOA
* remove debugging
* remove debugging from choco installs
* Revert "disable problematic test on WOA"
This reverts commit e060fb0839.
* Revert "remove debugging"
This reverts commit f18dd8b1a5.
* run against all the tests in the failing shard
* don't run visibility tests first
* remove debugging
* 3 is a magic number
* Revert "3 is a magic number"
This reverts commit 36b91ccf9f.
* match what Appveyor runs exactly
* Revert "match what Appveyor runs exactly"
This reverts commit 7260dd4322.
* chore: sort files alphabetically
* find out what spec is leaving stuff open
* chore: Checkout PR HEAD commit
instead of merge commit
* try using app.exit instead of process.exit
* test: cleanup BrowserWindows and webContents
* Revert "chore: sort files alphabetically"
This reverts commit d9e217ffb1.
* chore: use win32 to match process.platform
Needed for build-tools to download from PRs
* chore: cache yarn dir
* fixup cache yarn
* fixup use win32 to match process.platform
* fixup use win32 to match process.platform
* fixup cache yarn
* Add debugging for WOA hang
* Add debugging for failing keyboard lock test
* Revert "Add debugging for WOA hang"
This reverts commit 8df03d568d.
* try using process.kill
* add more debugging to keyboard.lock test
* Revert "Add debugging for failing keyboard lock test"
* remove debugging
* test: disable keyboard.lock on Windows
* test: disable fullscreen tests on Windows
* test: only force test suite exit on WOA
* fixup test: only force test suite exit on WOA
* cleanup tests
* extract yarn caching/install to action
* try using bash to run windows tests
* remove left over debugging
* standardize on 'win' for Windows builds
* use 'x86' for arch for manifest files
* fixup try using bash to run windows tests
* fixup use 'x86' for arch for manifest files
* standardize on 'win' for Windows builds
* fixup use 'x86' for arch for manifest files
* fixup try using bash to run windows tests
---------
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* fix: unused variable warning when the PDF viewer is disabled
* fix: unused function error when PDF viewer is disabled
error: unused function ParseManifest [-Werror,-Wunused-function]
* docs: clarify what session.clearData() with data type 'cache' deletes
* docs: include `shadercache`, too
Co-authored-by: John Kleinschmidt <kleinschmidtorama@gmail.com>
---------
Co-authored-by: John Kleinschmidt <kleinschmidtorama@gmail.com>
* chore: remove unused isolate argument from Cookies constructor
unused since the ginify cookies refactor in Mar 2020, commit 22202255
* fix: constructor only takes one arg now, so mark it explicit
* refactor: make kRelauncherArgSeparator private to relauncher.cc
* refactor: make kRelauncherTypeArg private to relauncher.cc
* refactor: remove unused type relauncher::CharType
* refactor: move private constants into standalone private namespace
* refactor: move kWaitEventName into the only function that uses it
* refactor: more return-braced-init-list, this time for v8 and gin objects
* refactor: more return-braced-init-list, this time for v8, gin, std, and base objects
* refactor: misc-use-internal-linkage warnings in context bridge
move impl functions into anonymous namespace so that they're not visible
to other compilation units:
- ExposeAPIInWorld()
- IsCalledFromMainWorld()
- OverrideGlobalPropertyFromIsolatedWorld()
- OverrideGlobalValueFromIsolatedWorld()
- TraceKeyPath()
* refactor: misc-use-internal-linkage warnings in skia util
move impl details into anonymous namespace so that they're not visible
to other compilation units:
- struct ScaleFactorPair
- kScaleFactorPairs[]
- GetScaleFactorFromPath()
- AddImageSkiaRepFromPath()
* refactor: misc-use-internal-linkage warnings in printing util
move impl details into anonymous namespace so that they're not visible
to other compilation units:
- GetFullPagePlugin()
* refactor: misc-use-internal-linkage warnings in blijnk converter
move impl details into anonymous namespace so that they're not visible
to other compilation units:
- GetKeyLocationCode()
- ModifiersToArray()
* refactor: misc-use-internal-linkage warnings in extrension system
move impl details into anonymous namespace so that they're not visible
to other compilation units:
- ParseManifest()
* refactor: misc-use-internal-linkage warnings in skia util
move impl details into anonymous namespace so that they're not visible
to other compilation units:
- GetFrameTokenMap()
- GetFrameTreeNodeIdMap()
* refactor: misc-use-internal-linkage warnings in electron_api_utility_process.cc
move impl details into anonymous namespace so that they're not visible
to other compilation units:
- GetAllUtilityProcessWrappers()
* refactor: misc-use-internal-linkage warnings in electron_api_menu
move impl details into anonymous namespace so that they're not visible
to other compilation units:
- InvokeBoolMethod()
* refactor: misc-use-internal-linkage warnings in platform util
move impl details into anonymous namespace so that they're not visible
to other compilation units:
- struct TrashItemResult
- TrashItemOnBlockingThread()
* refactor: avoid repeating the return type from the declaration; use a braced initializer list instead [modernize-return-braced-init-list]
* refactor: avoid repeating the return type from the declaration; use a braced initializer list instead [modernize-return-braced-init-list]
NB: using the braced-initializer list uncovered an error here:
the float returned by std::floor() can't be implicitly cast to
an int. This is solved by using base::ClampFloor<int>() instead.
std::floor()
* chore: remove unused local non-trivial variable relaunch_executable
became unused in June 2016 in 0d066de5
* chore: only declare program_name local variable if used
We declared it everywhere but only used it on Windows
* chore: remove unused local non-trivial variable path from UnregisterXWindow
it became unused in 2020 by 72a08926
* feat: add query-session-end event for Windows
* fix: remove debug line
* feat: notify with reason on session-end
* docs: add comments and return params
* docs: add same docs to the BrowserWindow
* fix: add shutdown reason if lParam == 0
* docs: remove 'force' word
* docs: revert multithreading.md change
* docs: add reasons documentation, reason variable renamed to reasons
* docs: improve 'shutdown' reason wording
* docs: reword with 'can be'
* fix: pass reasons by reference
* fix: use newer approach which expose reasons value directly on Event object
* docs: add escaping
* style: linter fixes
* fix: project now should compile
* fix: EmitWithoutEvent method added, EmitWithEvent moved to private again
* docs: typo fix
Co-authored-by: Sam Maddock <samuel.maddock@gmail.com>
* docs: dedicated WindowSessionEndEvent type created
* docs: better wording for session-end event description
Co-authored-by: Will Anderson <will@itsananderson.com>
---------
Co-authored-by: Sam Maddock <samuel.maddock@gmail.com>
Co-authored-by: Will Anderson <will@itsananderson.com>
* fix: performance-no-automatic-move in GetLogFileName()
remove `const` from log_filename.
Warning fixed by this commit:
../../electron/shell/common/logging.cc:40:12: warning: constness of 'log_filename' prevents automatic move [performance-no-automatic-move]
* fix: performance-no-automatic-move in GetBundleResourcePath()
remove `const` from request_relative_path.
Warning fixed by this commit:
electron/shell/browser/extensions/electron_extensions_browser_client.cc:187:10: warning: constness of 'request_relative_path' prevents automatic move [performance-no-automatic-move]
* refactor: use gdk_display_beep() to beep on Linux
* chore: make a stub declaration for gdk_display_beep()
* chore: remove unused file electron_gtk.sigs
* chore: remove unused #includes to make gn check happy
* fix: bugprone-narrowing-conversions warning in NativeImage::memory_usage_
- fix signed / unsigned math by using base/numerics/safe_conversions
- make memory_usage_ an int64_t so it can safely take the size_t
returned by computeByteSize()
Warning fixed by this commit:
../../electron/shell/common/api/electron_api_native_image.cc:155:26: warning: narrowing conversion from 'size_t' (aka 'unsigned long') to signed type 'int32_t' (aka 'int') is implementation-defined [bugprone-narrowing-conversions]
155 | new_memory_usage = image_skia->bitmap()->computeByteSize();
* fix: bugprone-narrowing-conversions warnings in NativeImage::CreateFromBitmap()
`SkImageInfo::MakeN32()` and `SkBitmap::allocN32Pixels()` both take int
width and height args, but we were feeding them unsigned ints.
../../electron/shell/common/api/electron_api_native_image.cc:508:36: warning: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions]
508 | auto info = SkImageInfo::MakeN32(width, height, kPremul_SkAlphaType);
| ^
../../electron/shell/common/api/electron_api_native_image.cc:508:43: warning: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions]
508 | auto info = SkImageInfo::MakeN32(width, height, kPremul_SkAlphaType);
| ^
../../electron/shell/common/api/electron_api_native_image.cc:524:25: warning: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions]
524 | bitmap.allocN32Pixels(width, height, false);
| ^
../../electron/shell/common/api/electron_api_native_image.cc:524:32: warning: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions]
524 | bitmap.allocN32Pixels(width, height, false);
| ^
../../electron/shell/common/api/electron_api_native_image.cc:528:48: warning: narrowing conversion from 'double' to 'float' [bugprone-narrowing-conversions]
528 | gfx::ImageSkia::CreateFromBitmap(bitmap, scale_factor);
fix: AutofillPopup warning: use '= default' to define a trivial default constructor [modernize-use-equals-default]
refactor: reduce #indclude scope in autofill_popup.h and autofill_popup_view.h
* chore: reland "fix: utility process exit code for graceful termination"
This reverts commit 1cae73ba09.
* fix: exit code on posix when killed via api
* chore: fix code style
* docs: Make ipcRenderer and ipcMain listener API docs consistent
* test: add some unit tests for ipcRenderer/ipcMain listener behavior
* fix: Mark on/off methods as primary and addListener/removeListener as aliases
* fix: clear all listeners before running ipcMain removeAllListeners tests
* feat: add support for configuring xdg portal version at runtime
* doc: update command-line-switches.md
* doc: update command-line-switches.md
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* doc: required portal version for defaultPath support
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* doc: update more occurrances
* fix: remove warning from save dialogs
* doc: update command-line-switches.md
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
---------
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
Closes https://github.com/electron/electron/issues/44569.
Fixes an issue where the WCO buttons were hidden on Linux in fullscreen mode
but not on Windows or macOS. The Windows behavior is the expected one, so this
commit makes the Linux behavior consistent.
Update Squirrel Run at Login docs to be modern
The current docs for setting up Run at Login use the legacy way that
Squirrel does shortcuts. This was replaced by an easier method, let's
use that instead
* fix: flake wait for crash with specific serviceName
* fix: flake when unrelated WebContents exists during BrowserView tests
* fix: wait for crash before forking
* use name
* fix: Use openURL:configuration:completionHandler instead of openUrl
* test: add a test
* fix: add dispatch_async to replace GetUIThreadTaskRunner
* refactor: remove unused import
* fix: update to use BindPostTaskToCurrentDefault
* test: add regression test for window focus
* refactor: update to explicit task runner
* refactor: move uv_setup_args() calls to startup
* refactor: call base::CommandLine::Init() before ContentMain()
* feat: add ElectronCommandLine::AsUtf8()
* refactor: call base::CommandLine::Init() before NodeMain()
* refactor: use ElectronCommandLine::AsUtf8() in NodeMain()
* fix: -Wunsafe-buffer-usage warning in ElectronCommandLine::Init()
* chore: add a DCHECK to confirm ElectronCommandLine was initialized before AsUtf8() is called
* chore: const correctness in ElectronCommandLine::Init() args
* chore: add ElectronCommandLine to macOS Electron Helper app
* chore: move argc, argvc setup into electron_library_main on macOS
* chore: revert BUILD.gn changes
* fix: WideToUTF8() call in ElectronCommandLine::AsUtf8()
* build: add uv to the include paths for app/electron_main_linux
* build: add uv to the include paths for app/electron_library_main.mm
* chore: revert unrelated changes
these were intended for another branch
* refactor: BaseWindow::OnExecuteAppCommand() now takes a std::string_view
* refactor: NativeWindow::NotifyWindowExecuteAppCommand() takes a std::string_view
* refactor: AppCommandToString() returns a std::string_view, is now constexpr
* refactor: make kBrowserBackward, kBrowserForward inline constexpr std::string_view
Xref: https://abseil.io/tips/140https://groups.google.com/a/chromium.org/g/chromium-dev/c/jROTxMo_m2Q/m/HgciN2KsAgAJ
* refactor: use inline constexpr string_view for kDevice*Key constants
Xref: https://abseil.io/tips/140https://groups.google.com/a/chromium.org/g/chromium-dev/c/jROTxMo_m2Q/m/HgciN2KsAgAJ
* refactor: IsEnvSet now takes a base::cstring_view
* refactor: use inline constexpr cstring_view for kRunAsNode
* refactor: use inline constexpr string_view for kPDF*PluginName
* refactor: use base::FilePath::FromASCII() since "internal-pdf-viewer" is ascii
* chore: remove unused shell/common/electron_constants.cc
* fixup! refactor: IsEnvSet now takes a base::cstring_view
* perf: prefer NewFromUtf8Literal() over NewFromUtf8() for string literals
the string length is known at compile time and no need to call ToLocalChecked()
* perf: string length is known when calling NewFromUtf8(), so use it
* perf: remove unnecessary calls to c_str()
these just force the code being called to have to recalculate the string length
* chore: move as_byte_span() to new shell/common/mac_util.h
this way it can be used by multiple mm files
* fix: -Wunsafe-buffer-usage warnings in UNNotificationResponseToNSDictionary
* refactor: use base::HexEncode() instead of rolling our own
* fixup! chore: move as_byte_span() to new shell/common/mac_util.h
* fixup! chore: move as_byte_span() to new shell/common/mac_util.h
fix: move mac_util to the right place in filenames.gni
Node PR: https://github.com/nodejs/node/pull/55306
Do not merge before attached Node PR is merged. This PR updates our NMV to 132 for Electron 34
Please merge this PR before branching 34-x-y
* refactor: const correctness
* refactor: extract-method AsarFileValidator::EnsureHashExists()
* refactor: replace use of deprecated crypto API
https://crbug.com/364687923
* refactor: use span API in AsarFileValidator::OnRead()
* refactor: replace use of deprecated crypto API
https://crbug.com/364687923
* fixup! refactor: use span API in AsarFileValidator::OnRead()
fix: electron-ia32-testing FTBFS
perf: use ArrayBuffer::Data() API
Replace our `GetBackingStore()->Data()` calls with this instead.
Explained by the V8 docs, ArrayBuffer.Data() is
> More efficient shortcut for GetBackingStore()->Data(). The
> returned pointer is valid as long as the ArrayBuffer is alive.
* build: convert all release scripts to typescript
* fix test imports
* build: fix version bumper export
* refactor: use as const
* spec: fix bad type spec
fix: -Wunsafe-buffer-usage warnings in ElectronComponentExtensionResourceManager::AddComponentResourceEntries()
just replace pointer-and-length args with a span
* fix: do not build electron_plugin_info_host_impl.cc when plugins are disabled
it fails to build from source with this error:
../../content/public/browser/plugin_service.h:17:2: error: "Plugins should be enabled"
17 | #error "Plugins should be enabled"
* fix: FTBFS in printing_utils.cc when ENABLE_PDF is false
* fixup! fix: do not build electron_plugin_info_host_impl.cc when plugins are disabled
fix BUILD.gn linting
* feat: add error event for utility process
* chore: use public report api
* chore: fix lint
* doc: mark error event as experimental
---------
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
* fix: -Wunsafe-buffer-usage warnings in GdkPixbufFromSkBitmap()
* refactor: don't change previous behavior for 0-height images
Is a 0x0 image even a thing? I'm not sure; but just in case, let's
treat it the same way the previous implementation did.
test: expect a `sender-pid` hint in Linux notifications.
This PR ensures that the `sender-pid` hint is set for new notifications.
It also updates the spec to confirm that DBus receives the hint and that
it has the correct value.
This fixes a spec failure when running libnotify >= 0.7.12 (2022-05-05).
Starting with that version, libnotify started injecting `sender-pid` if
not provided by the client. So our tests received a slightly different
DBus payload depending on what version of libnotify was installed,
causing our deep-equals tests to fail.
By always providing and testing the `sender-pid` hint, our behavior and
tests should be consistent across distros.
Provide a NativeImage icon in the notification tests and then inspect
the DBus message payload's `image_data` hint to see if it's correct.
This adds test coverage for LibnotifyNotification::Show() and for
GdkPixbufFromSkBitmap().
Right now DelayedNativeViewHost attaches its underlying native view
when it's being attached to a widget but it doesn't detach it when
it's being detached. It may lead to use-after-free and crash.
Add a `base::WeakPtr<WebContents>` field to SerialChooserController and
stop subclassing from WebContentsObserver. This follows the Observer docs:
> don't create a `WebContentsObserver` just to be able to check
> for a null `WebContentsObserver::web_contents()`.
> Use a `base::WeakPtr<WebContents>` instead.
prefactor: prefer member initializers in asar::Archive
prefactor: prefer member initializers in asar::Archive::FileInfo
prefactor: prefer member initializers in asar::IntegrityPayload
* build: add support for fetching github token from sudowoodo
* chore: update release notes cache for tests
* build: support nightlies repo correctly
* build: post token
Because we used decrementing negative source ids for fake video id when
instantating a native macOS screen share picker, we eventually hit the
`DesktopMediaID::kFakeId = -3` in Chromium source code which displayed a
test green screen.
In this change we reserve our own fake id of `-4` and decrement the
window id integer for uniqueness instead.
Co-authored-by: Fedor Indutny <238531+indutny@users.noreply.github.com>
* refactor: CallMethodWithArgs() now takes a span of value handles
* perf: use std::array instead of std::vector to hold Emit arg parameter packs
* chore: remove unused gin_helper::EmitEvent(iso, obj, name, span<Local>)
* chore: iwyu mojom.h headers
* fixup! chore: iwyu mojom.h headers
make previously-indirect include dependency direct
* fixup! fixup! chore: iwyu mojom.h headers
make previously-indirect include dependency direct
Closes https://github.com/electron/electron/issues/43714.
Fixes an issue where the resizing border was not being handled correctly on Linux WCO
caption buttons. This is now taken into account as a part of the NonClientHitTest.
* refactor: move scope scaffolding into SettletScope
idea stolen from SpellCheckScope
* refactor: move impl of PromiseBase::RejectPromise() to the cc file
* chore: remove unused #include
* chore: move Archaeologist to GHA
* chore: test archaelogist changes
* Revert "chore: test archaelogist changes"
This reverts commit a575d6ef3a.
* chore: properly name steps in archaeologist-dig
refactor: avoid redundant Promise.GetContext calls
Several Promise methods call `GetContext()` multiple times. From looking
at the assembly in obj/electron/electron_lib/promise.o, these redundant
calls are actually being made -- they aren't optmized out.
This PR keeps the return value in a local variable to avoid extra calls.
refactor: take a uint8_t span in ValidateIntegrityOrDie()
Doing some groundwork for fixing unsafe base::File() APIs:
- Change ValidateIntegrityOrDie() to take a span<const uint8_t> arg.
We'll need this to migrate asar's base::File API calls away from the
ones tagged `UNSAFE_BUFFER_USAGE` because the safe counterparts use
span<uint8_t> too.
- Simplify ValidateIntegrityOrDie()'s implementation by using
crypto::SHA256Hash() instead of reinventing the wheel.
Use v8::ArrayBufferView::CopyContents() instead of doing the pointer
math + memcpy() ourselves. This not only solves the buffer warnings,
but may also avoid some additional overhead:
> Copy the contents of the ArrayBufferView's buffer to an
> embedder defined memory without additional overhead that
> calling ArrayBufferView::Buffer might incur.
* fix: Launch apps with XDG_ACTIVATION_TOKEN in ozone/wayland
Ensure apps are launched with the activation token received from
xdg_activation_v1 protocol.
* add focus_launched_process option
* fix: remove use of deprecated v8::String::Value
Upstream marked v8::String::Value as `V8_DEPRECATE_SOON` last month,
so let's stop using it.
The replacement code mostly does the same as v8::String::Value();
but since our test only cares about the length and not the contents,
we get a small perf win of not needing to allocate a char array and
not needing to call Local::String::Write().
Upstream V8_DEPRECATE_SOON:
Xref: https://chromium-review.googlesource.com/c/v8/v8/+/5667299kkk
v8::String::Value() implementation:
20226b740b/src/api/api.cc (10883)
History on why we used it:
80c1a9739df49ed30f72
* Update shell/common/gin_converters/file_path_converter.h
Co-authored-by: Robo <hop2deep@gmail.com>
* fixup! Update shell/common/gin_converters/file_path_converter.h
do not return success for all non-Null non-Strings
---------
Co-authored-by: Robo <hop2deep@gmail.com>
When an electron app is launched by another app ensure that the
XDG_ACTIVATION_TOKEN env var is read and used for activation using
xdg_activation_v1 protocol.
* fix: systemMediaPermissionDenied: should check for screen capture perms instead of camera
* Revert "fix: systemMediaPermissionDenied: should check for screen capture perms instead of camera"
This reverts commit e9cc672165.
* should only do these checks for audio or video, but not screenshare
* no service
* oops
---------
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* fix: -Wunsafe-buffer-usage warnings in IsUrlArg()
* chore: improve code comments for CheckCommandLineArguments()
* chore: reduce diffs from main
* refactor: CheckCommandLineArguments takes a StringVector arg
Fixes another buffer warning!
* chore: avoid double-call to url.scheme() in WebContentsZoomController::SetZoomMode()
* perf: use gurl.scheme_piece() in GetAppInfoHelperForProtocol()
* perf: use gurl.scheme_piece() in Browser::GetApplicationNameForProtocol()
* refactor: add std::less<> to HandlersMap
This lets us search it using string_view keys
* refactor: ProtocolRegistry::FindRegistered() now takes a std::string_view
* perf: use gurl.scheme_piece() in InspectableWebContents::LoadNetworkResource()
* refactor: ProtocolRegistry::FindIntercepted() now takes a std::string_view
* perf: use gurl.scheme_piece() in SimpleURLLoaderWrapper::GetURLLoaderFactoryForURL()
* perf: use gurl.scheme_piece() in ProxyingURLLoaderFactory::CreateLoaderAndStart()
* perf: use gurl.host_piece() in ElectronWebUIControllerFactory::GetWebUIType()
* perf: use gurl.host_piece() in ElectronWebUIControllerFactory::CreateWebUIControllerForURL()
We use [semantic commit messages](https://github.com/electron/electron/blob/main/docs/development/pull-requests.md#commit-message-guidelines) to streamline the release process. Before your pull request can be merged, you should **update your pull request title** to start with a semantic prefix.
Examples of commit messages with semantic prefixes:
@@ -10,6 +12,13 @@ newPRWelcomeComment: |
- `feat: add app.isPackaged() method`
- `docs: app.isDefaultProtocolClient is now available on Linux`
### Commit signing
This 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).
### PR tips
Things that will help get your PR across the finish line:
- Follow the JavaScript, C++, and Python [coding style](https://github.com/electron/electron/blob/main/docs/development/coding-style.md).
Emitted when a session is about to end due to a shutdown, machine restart, or user log-off. Once this event fires, there is no way to prevent the session from ending.
#### Event: 'blur'
@@ -1429,3 +1443,4 @@ On Linux, the `symbolColor` is automatically calculated to have minimum accessib
Emitted when a session is about to end due to a shutdown, machine restart, or user log-off. Once this event fires, there is no way to prevent the session from ending.
#### Event: 'unresponsive'
@@ -1549,13 +1563,17 @@ there is only one tab in the current window.
Adds a window as a tab on this window, after the tab for the window instance.
#### `win.setVibrancy(type)` _macOS_
#### `win.setVibrancy(type[, options])` _macOS_
* `type` string | null - Can be `titlebar`, `selection`, `menu`, `popover`, `sidebar`, `header`, `sheet`, `window`, `hud`, `fullscreen-ui`, `tooltip`, `content`, `under-window`, or `under-page`. See
the [macOS documentation][vibrancy-docs] for more details.
* `options` Object (optional)
* `animationDuration` number (optional) - if greater than zero, the change to vibrancy will be animated over the given duration (in milliseconds).
Adds a vibrancy effect to the browser window. Passing `null` or an empty string
will remove the vibrancy effect on the window.
will remove the vibrancy effect on the window. The `animationDuration` parameter only
animates fading in or fading out the vibrancy effect. Animating between
@@ -350,7 +360,7 @@ On Windows the options are more limited, due to the Win32 APIs used:
## Bookmarks array
`showOpenDialog`, `showOpenDialogSync`, `showSaveDialog`, and `showSaveDialogSync` will return a `bookmarks` array.
`showOpenDialog` and `showSaveDialog` resolve to an object with a `bookmarks` field. This field is an array of Base64 encoded strings that contain the [security scoped bookmark](https://developer.apple.com/library/content/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW16) data for the saved file. The `securityScopedBookmarks` option must be enabled for this to be present.
| Build Type | securityScopedBookmarks boolean | Return Type | Return Value |
_This class is not exported from the `'electron'` module. It is only available as a return value of other methods in the Electron API._
Each navigation entry corresponds to a specific page. The indexing system follows a sequential order, where the first available navigationentry is at index 0, representing the earliest visited page, and the latest navigation entry is at index N, representing the most recent page. Maintaining this ordered list of navigation entries enables seamless navigation both backward and forward through the user's browsing history.
Each [NavigationEntry](./structures/navigation-entry.md) corresponds to a specific visited page.
The indexing system follows a sequential order, where the entry for the earliest visited
page is at index 0 and the entry for the most recent visited page is at index N.
Some APIs in this class also accept an _offset_, which is an integer representing the relative
position of an index from the current entry according to the above indexing system (i.e. an offset
value of `1` would represent going forward in history by one page).
Maintaining this ordered list of navigation entries enables seamless navigation both backward and
forward through the user's browsing history.
### Instance Methods
@@ -21,7 +30,7 @@ Returns `boolean` - Whether the browser can go forward to next web page.
*`offset` Integer
Returns `boolean` - Whether the web page can go to the specified `offset` from the current entry.
Returns `boolean` - Whether the web page can go to the specified relative `offset` from the current entry.
#### `navigationHistory.clear()`
@@ -57,7 +66,7 @@ Navigates browser to the specified absolute web page index.
*`offset` Integer
Navigates to the specified offset from the current entry.
Navigates to the specified relative offset from the current entry.
#### `navigationHistory.length()`
@@ -74,3 +83,22 @@ Returns `boolean` - Whether the navigation entry was removed from the webContent
#### `navigationHistory.getAllEntries()`
Returns [`NavigationEntry[]`](structures/navigation-entry.md) - WebContents complete history.
#### `navigationHistory.restore(options)`
Restores navigation history and loads the given entry in the in stack. Will make a best effort
to restore not just the navigation stack but also the state of the individual pages - for instance
including HTML form values or the scroll position. It's recommended to call this API before any
navigation entries are created, so ideally before you call `loadURL()` or `loadFile()` on the
`webContents` object.
This API allows you to create common flows that aim to restore, recreate, or clone other webContents.
*`options` Object
*`entries` [NavigationEntry[]](structures/navigation-entry.md) - Result of a prior `getAllEntries()` call
*`index` Integer (optional) - Index of the stack that should be loaded. If you set it to `0`, the webContents will load the first (oldest) entry. If you leave it undefined, Electron will automatically load the last (newest) entry.
Returns `Promise<void>` - the promise will resolve when the page has finished loading the selected navigation entry
(see [`did-finish-load`](web-contents.md#event-did-finish-load)), and rejects
if the page fails to load (see
[`did-fail-load`](web-contents.md#event-did-fail-load)). A noop rejection handler is already attached, which avoids unhandled rejection errors.
Emitted when a service worker has been registered. Can occur after a call to [`navigator.serviceWorker.register('/sw.js')`](https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/register) successfully resolves or when a Chrome extension is loaded.
*`versionId` number - ID of the updated service worker version
*`runningStatus` string - Running status.
Possible values include `starting`, `running`, `stopping`, or `stopped`.
Emitted when a service worker's running status has changed.
### Instance Methods
The following methods are available on instances of `ServiceWorkers`:
@@ -64,10 +75,55 @@ The following methods are available on instances of `ServiceWorkers`:
Returns `Record<number, ServiceWorkerInfo>` - A [ServiceWorkerInfo](structures/service-worker-info.md) object where the keys are the service worker version ID and the values are the information about that service worker.
*`versionId` number - ID of the service worker version
Returns [`ServiceWorkerMain | undefined`](service-worker-main.md) - Instance of the service worker associated with the given version ID. If there's no associated version, or its running status has changed to 'stopped', this will return `undefined`.
*`colorDepth` number - The number of bits per pixel.
*`colorSpace` string - represent a color space (three-dimensional object which contains all realizable color combinations) for the purpose of color conversions.
*`depthPerComponent` number - The number of bits per color component.
*`detected` boolean - `true`` if the display is detected by the system.
*`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 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.
*`type` String - Possible values include `service-worker`.
*`serviceWorker` [ServiceWorkerMain](../service-worker-main.md) _Readonly_ - The service worker that sent this message
*`versionId` Number - The service worker version ID.
*`session` Session - The [`Session`](../session.md) instance with which the event is associated.
*`returnValue` any - Set this to the value to be returned in a synchronous message
*`ports` [MessagePortMain](../message-port-main.md)[] - A list of MessagePorts that were transferred with this message
*`reply` Function - A function that will send an IPC message to the renderer frame that sent the original message that you are currently handling. You should use this method to "reply" to the sent message in order to guarantee the reply will go to the correct process and frame.
*`scriptUrl` string - The full URL to the script that this service worker runs
*`scope` string - The base URL that this service worker is active for.
*`renderProcessId` number - The virtual ID of the process that this service worker is running in. This is not an OS level PID. This aligns with the ID set used for `webContents.getProcessId()`.
*`versionId` number - ID of the service worker version
*`urls` string[] - Array of [URL patterns](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Match_patterns) that will be used to filter out the requests that do not match the URL patterns.
*`types`String[] (optional) - Array of types that will be used to filter out the requests that do not match the types. When not specified, all types will be matched. Can be `mainFrame`, `subFrame`, `stylesheet`, `script`, `image`, `font`, `object`, `xhr`, `ping`, `cspReport`, `media` or `webSocket`.
*`urls` string[] - Array of [URL patterns](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Match_patterns) used to include requests that match these patterns. Use the pattern `<all_urls>` to match all URLs.
*`excludeUrls`string[] (optional) - Array of [URL patterns](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Match_patterns) used to exclude requests that match these patterns.
*`types` string[] (optional) - Array of types that will be used to filter out the requests that do not match the types. When not specified, all types will be matched. Can be `mainFrame`, `subFrame`, `stylesheet`, `script`, `image`, `font`, `object`, `xhr`, `ping`, `cspReport`, `media` or `webSocket`.
@@ -12,6 +12,98 @@ This document uses the following convention to categorize breaking changes:
* **Deprecated:** An API was marked as deprecated. The API will continue to function, but will emit a deprecation warning, and will be removed in a future release.
* **Removed:** An API or feature was removed, and is no longer supported by Electron.
## Planned Breaking API Changes (35.0)
### Behavior Changed: Dialog API's `defaultPath` option on Linux
On Linux, the required portal version for file dialogs has been reverted
to 3 from 4. Using the `defaultPath` option of the Dialog API is not
supported when using portal file chooser dialogs unless the portal
backend is version 4 or higher. The `--xdg-portal-required-version`
Additionally, `level` is now a string with possible values of `info`, `warning`, `error`, and `debug`.
### Behavior Changed: `urls` property of `WebRequestFilter`.
Previously, an empty urls array was interpreted as including all URLs. To explicitly include all URLs, developers should now use the `<all_urls>` pattern, which is a [designated URL pattern](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Match_patterns#all_urls) that matches every possible URL. This change clarifies the intent and ensures more predictable behavior.
### Behavior Changed: menu bar will be hidden during fullscreen on Windows
This brings the behavior to parity with Linux. Prior behavior: Menu bar is still visible during fullscreen on Windows. New behavior: Menu bar is hidden during fullscreen on Windows.
**Correction**: This was previously listed as a breaking change in Electron 33, but was first released in Electron 34.
## Planned Breaking API Changes (33.0)
### Deprecated: `document.execCommand("paste")`
@@ -40,15 +132,15 @@ immediately upon being received. Otherwise, it's not guaranteed to point to the
same webpage as when received. To avoid misaligned expectations, Electron will
return `null` in the case of late access where the webpage has changed.
```ts
```js
ipcMain.on('unload-event',(event)=>{
event.senderFrame;// ✅ accessed immediately
});
event.senderFrame// ✅ accessed immediately
})
ipcMain.on('unload-event',async(event)=>{
awaitcrossOriginNavigationPromise;
event.senderFrame;// ❌ returns `null` due to late access
});
awaitcrossOriginNavigationPromise
event.senderFrame// ❌ returns `null` due to late access
})
```
### Behavior Changed: custom protocol URL handling on Windows
@@ -95,6 +187,16 @@ macOS 10.15 (Catalina) is no longer supported by [Chromium](https://chromium-rev
Older versions of Electron will continue to run on Catalina, but macOS 11 (Big Sur)
or later will be required to run Electron v33.0.0 and higher.
### Behavior Changed: Native modules now require C++20
Due to changes made upstream, both
[V8](https://chromium-review.googlesource.com/c/v8/v8/+/5587859) and
[Node.js](https://github.com/nodejs/node/pull/45427) now require C++20 as a
minimum version. Developers using native node modules should build their
modules with `--std=c++20` rather than `--std=c++17`. Images using gcc9 or
lower may need to update to gcc10 in order to compile. See
[#43555](https://github.com/electron/electron/pull/43555) for more details.
The `systemPreferences.accessibilityDisplayShouldReduceTransparency` property is now deprecated in favor of the new `nativeTheme.prefersReducedTransparency`, which provides identical information and works cross-platform.
@@ -69,8 +69,25 @@ if (navigationHistory.canGoToOffset(2)) {
}
```
## Restoring history
A common flow is that you want to restore the history of a webContents - for instance to implement an "undo close tab" feature. To do so, you can call `navigationHistory.restore({ index, entries })`. This will restore the webContent's navigation history and the webContents location in said history, meaning that `goBack()` and `goForward()` navigate you through the stack as expected.
@@ -116,6 +116,7 @@ You should at least follow these steps to improve the security of your applicati
17. [Validate the `sender` of all IPC messages](#17-validate-the-sender-of-all-ipc-messages)
18. [Avoid usage of the `file://` protocol and prefer usage of custom protocols](#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols)
19. [Check which fuses you can change](#19-check-which-fuses-you-can-change)
20. [Do not expose Electron APIs to untrusted web content](#20-do-not-expose-electron-apis-to-untrusted-web-content)
To automate the detection of misconfigurations and insecure patterns, it is
possible to use
@@ -229,7 +230,7 @@ API to remotely loaded content via the [contextBridge API](../api/context-bridge
### 3. Enable Context Isolation
:::info
This recommendation is the default behavior in Electron since 12.0.0.
Context Isolation is the default behavior in Electron since 12.0.0.
:::
Context isolation is an Electron feature that allows developers to run code
@@ -804,6 +805,48 @@ flipping these fuses easy. Check out the README of that module for more details
potential error cases, and refer to
[How do I flip the fuses?](./fuses.md#how-do-i-flip-the-fuses) in our documentation.
### 20. Do not expose Electron APIs to untrusted web content
You should not directly expose Electron's APIs, especially IPC, to untrusted web content in your
preload scripts.
### Why?
Exposing raw APIs like `ipcRenderer.on` is dangerous because it gives renderer processes direct
access to the entire IPC event system, allowing them to listen for any IPC events, not just the ones
intended for them.
To avoid that exposure, we also cannot pass callbacks directly through: The first
argument to IPC event callbacks is an `IpcRendererEvent` object, which includes properties like `sender`
that provide access to the underlying `ipcRenderer` instance. Even if you only listen for specific
events, passing the callback directly means the renderer gets access to this event object.
In short, we want the untrusted web content to only have access to necessary information and APIs.
@@ -8,7 +8,7 @@ If your app doesn't use any native modules, then it's really easy to create an A
1. Make sure that your app's `node_modules` directory is empty.
2. Using a _Command Prompt_, run `set npm_config_arch=arm64` before running `npm install`/`yarn install` as usual.
3. [If you have Electron installed as a development dependency](quick-start.md#prerequisites), npm will download and unpack the arm64 version. You can then package and distribute your app as normal.
3. [If you have Electron installed as a development dependency](tutorial-2-first-app.md#initializing-your-npm-project), npm will download and unpack the arm64 version. You can then package and distribute your app as normal.
Electron is a framework enabling developers to build cross-platform desktop applications for macOS, Windows, and Linux by combining web technologies (HTML, JavaScript, CSS) with Node.js and native code. It is open-source, MIT-licensed, and free for both commercial and personal use. In this document, we’ll explain why companies and developers choose Electron.
We can split up the benefits of Electron in two questions: First, why should you use web technologies to build your application? Then, why should you choose Electron as the framework to do so?
If you’re already using web technologies for your application, you can skip straight to the `Why Electron?` section below.
## Why choose web technologies
Web technologies include HTML, CSS, JavaScript, and WebAssembly. They’re the storefront of the modern Internet. Those technologies have emerged as the best choice for building user interfaces — both for consumer applications as well as mission-critical business applications. This is true both for applications that need to run in a browser as well as desktop applications that are not accessible from a browser. Our bold claim here is that this isn’t just true for cross-platform applications that need to run on multiple operating systems but true overall.
As an example, NASA’s actual [Mission Control](https://github.com/nasa/openmct) is written with web technologies. The [Bloomberg Terminal](https://en.wikipedia.org/wiki/Bloomberg_Terminal), the computer system found at every financial institution, is written with web technologies and runs inside Chromium. It costs $25,000 per user, per year. The McDonald’s ordering kiosk, powering the world’s biggest food retailer, is entirely built with Chromium. The [SpaceX’s Dragon 2 space capsule](https://old.reddit.com/r/spacex/comments/gxb7j1/we_are_the_spacex_software_team_ask_us_anything/ft62781/?context=3) uses Chromium to display its interface. You get the point: web technologies are a great tech stack to build user interfaces.
Here are the reasons we, the Electron maintainers, are betting on the web.
### Versatility
Modern versions of HTML and CSS enable your developers and designers to fully express themselves. The web’s showcase includes Google Earth, Netflix, Spotify, Gmail, Facebook, Airbnb, or GitHub. Whatever interface your application needs, you will be able to express it with HTML, CSS, and JavaScript.
If you want to focus on building a great product without figuring out how you can realize your designer’s vision in a specific UI framework, the web is a safe bet.
### Reliability
Web technologies are the most-used foundation for user interfaces on the planet. The have been hardened accordingly. Modern computers have been optimized from the CPU to the operating system to be good at running web technologies. The manufacturers of your user’s devices—be that an Android phone or the latest MacBook—will ensure that they can visit websites, play videos on YouTube, or display emails. In turn, they’ll also ensure that your app has a stable foundation, even if you have just one user.
If you want to focus on building a great product without debugging a weird quirk that nobody has found before, the web is a safe bet.
### Interoperability
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 safe bet if you want to be cross-platform.
### Ubiquity
It’s easy to find developers with experience building with web technologies. If you’re a developer, it’ll be easy to find answers to your questions on Google, Stack Overflow, GitHub, or a coding AI of your choice. Whatever problem you need to solve, it’s likely that somebody has solved it well before—and that you can find the answer to the puzzle online.
If you want to focus on building a great product with ample access to resources and materials, the web is a safe bet.
## Why choose Electron
Electron combines Chromium, Node.js, and the ability to write custom native code into one framework for building powerful desktop applications. There are three main reasons to use Electron:
### Enterprise-grade
Electron is reliable, secure, stable, and mature. It is the premier choice for companies building their flagship product. We have a list of some of those companies on our homepage, but just among chat apps, Slack, Discord, and Skype are built with Electron. Among AI applications, both OpenAI’s ChatGPT and Anthropic’s Claude use Electron. Visual Studio Code, Loom, Canva, Notion, Docker, and countless other leading developers of software bet on Electron.
We did make it a priority to make Electron easy to work with and a delight for developers. That’s likely the main reason why Electron became as popular as it is today — but what keeps Electron alive and thriving is the maintainer’s focus on making Electron as stable, secure, performant, and capable of mission-critical use cases for end users as possible. We’re building an Electron that is ready to be used in scenarios where unfixable bugs, unpatched security holes, and outages of any kind are worst-case scenarios.
### Mature
Our current estimation is that most desktop computers on the planet run at least one Electron app. Electron has grown by prioritizing talent in its maintainer group, fostering excellent and sustainable engineering practices in managing the ongoing maintenance, and proactively inviting companies betting on Electron to directly contribute to the project. We’re an impact project with the OpenJS foundation, which is itself a part of the Linux foundation. We share resources and expertise with other foundation projects like Node.js, ESLint, Webpack - or the Linux Kernel or Kubernetes.
What does all of that mean for you, a developer, in practice?
- **Reliable release schedule**: Electron will release a new major version in lockstep with every second major Chromium release, usually on the same day as Chromium. A lot of work, both in the form of building processes and tools, but also in terms of raw invested hours every week, has to go into making that happen.
- **No dictators**: Sometimes, betting on a technology also requires you to bet on a single person or company. In turn, it requires you to trust that the person or company never has a breakdown, starts fighting you directly, or does anything else drastic that’ll force you rethink your entire tech stack. Electron is maintained by a diverse set of companies (Microsoft, Slack/Salesforce, Notion, and more) and will continue to welcome more companies interested in ensuring their “seat at the decision-making table”.
### 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 upmost stability, security, and performance, we currently believe that stack to be “best in class”.
#### Why bundle anything at all
You might wonder why we bundle Chromium’s web stack with our apps when most modern operating systems already ship a browser and some form of web view. Bundling doesn’t just increase the amount of work for Electron maintainers dramatically, it also increases the total disk size of Electron apps (most apps are >100MB). Many Electron maintainers once developed applications that did make use of embedded web views — and have since accepted the increased disk size and maintainer work as a worthy trade-off.
When using an operating system's built-in web view, you're limited by the browser version included in the oldest operating system version you need to support. We have found the following problems with this approach:
- **Stability**: The modern web technology stack is complex, and as a result, you’ll sooner or later encounter bugs. If you use the operating system’s web view, your only recourse will be to ask your customers to upgrade their operating system. If no upgrade is available for that machine (because of no ability to upgrade to the latest macOS or Windows 11), you’ll have to ask them to buy a new computer. If you’re unlucky, you’re now losing a major customer because they will not upgrade their entire fleet of thousands of machines just because one team wanted to try your startup’s app. You have _no recourse_ in this situation. Even the risk of that happening is unacceptable to the companies that employ the Electron maintainers.
- **Security:** Similar to how you can fix stability bugs by releasing an app update, you can also release security fixes to your application without asking your customer to upgrade their operating system. Even if operating system providers prioritize updates to their built-in browser, we have not seen them reliably update the built-in web views with similar urgency. Bundling a web renderer gives you, the developer, control.
- **Performance:** For simple HTML documents, a built-in web view will sometimes use fewer resources than an app with a bundled framework. For bigger apps, it is our experience that we can deliver better performance with the latest version of Chromium than we can with built-in web views. You might think that the built-in view can share a lot of resources with other apps and the operating system— but for security reasons, apps have to run in their own sandboxes, isolated from each other. At that point, the question is whether the OS’ web view is more performant than Chromium. Across many apps, our experience is that bundling Chromium and Node.js enables us to build better and more performant experiences.
#### Why bundle Chromium and Node.js
Electron aims to enable the apps it supports to deliver the best possible user experience, followed by the best possible developer experience. Chromium is currently the best cross-platform rendering stack available. Node.js uses Chromium’s JavaScript engine V8, allowing us to combine the powers of both.
- **Native code when you want it**: Thanks to Node.js’ mature native addon system, you can always write native code. There is no system API out of reach for you. Whatever macOS, Windows, or Linux feature you’ll want to integrate with —as long as you can do it in C, C++, Objective-C, Rust, or another native language, you’ll be able to do it in Electron. Again, this gives you, the developer, maximum control. With Electron, you can use web technologies without choosing _only_ web technologies.
### Developer experience
To summarize, we aim to build an Electron that is mature, enterprise-grade, and ready for mission-critical applications. We prioritize reliability, stability, security, and performance. That said, you might also choose Electron for its developer experience:
- **Powerful ecosystem**: Anything you find on npm will run inside Electron. Any resource available to you about how to work with Node.js also applies to Electron. In addition, Electron itself has a [thriving ecosystem](https://www.npmjs.com/search?q=electron) — including plenty of choices for installers, updaters, deeper operating system-integration, and more.
- **Plenty of built-in capabilities:** Over the last ten years, Electron’s core has gained plenty of native capabilities that you might need to build your application. Written in C++ and Objective-C, Electron has [dozens of easy-to-use APIs for deeper operating-system integration](https://www.electronjs.org/docs/latest/api/app) — like advanced window customization for transparent or oddly shaped widgets, receiving push notifications from the Apple Push Notification Network, or handling a custom URL protocol for your app.
- **Open source**: The entire stack is open source and open to your inspection. This ensures your freedom to add any feature or fix any bug you might encounter in the future.
- **Native code when you need it:** It bears repeating that Electron allows you to mix and match web technologies and C++, C, Objective-C, Rust, and other native languages. Whether it be SQLite, a whole LLM, or just the ability to call one specific native API, Electron will make it easy.
---
## Why choose something else
As outlined above, the web is an amazing platform for building interfaces. That doesn’t mean that we, the maintainers, would build _everything_ with HTML and CSS. Here are some notable exceptions:
**Resource-Constrained Environments and IoT:** In scenarios with very limited memory or processing power (say, one megabyte of memory and 100MHz of processing power on a low-powered ARM Cortex-M), you will likely need to use a low-level language to directly talk to the display to output basic text and images. Even on slightly higher-powered single-chip devices you might want to consider an embedded UI framework. A classic example is a smart watch.
**Small Disk Footprint**: Zipped Electron apps are usually around 80 to 100 Megabytes. If a smaller disk footprint is a hard requirement, you’ll have to use something else.
**Operating System UI Frameworks and Libraries**: By allowing you to write native code, Electron can do anything a native application can do, including the use of the operating system’s UI components, like WinUI, SwiftUI, or AppKit. In practice, most Electron apps make rare use of that ability. If you want the majority of your app to be built with operating system-provided interface components, you’ll likely be better off building fully native apps for each operating system you’d like to target. It’s not that it’s impossible with Electron, it’ll just likely be an overall easier development process.
**Games and Real-Time Graphics:** If you're building a high-performance game or application requiring complex real-time 3D graphics, native frameworks like Unity, Unreal Engine, or DirectX/OpenGL will provide better performance and more direct access to graphics hardware. Web fans might point out caveats, like the fact that even Unreal Engine ships with Chromium — or that WebGPU and WebGL are developing rapidly and many game engines, including the ones listed here, can now output their games in a format that runs in a browser. That said, if you asked us to build the next AAA game, we’d likely use something else than just web technologies.
**Embedding Lightweight Websites**: Electron apps typically are mostly web apps with native code sprinkled in where useful. Processing-heavy Electron applications tend to write the UI in HTML/CSS and build the backend in Rust, C++, or another native language. If you’re planning to build a primarily native application that also wants to display a little website in a specific view, you might be better off using the OS-provided web view or something like [ultralight](https://ultralig.ht/).
// Add a no-op rejection handler to silence the unhandled rejection error.
p.catch(()=>{});
this._loadURL(url,options??{});
@@ -549,6 +553,8 @@ WebContents.prototype.goToOffset = function (index: number) {
returnthis._goToOffset(index);
};
constconsoleMessageDeprecated=deprecate.warnOnceMessage('\'console-message\' arguments are deprecated and will be removed. Please use Event<WebContentsConsoleMessageEventParams> object instead.');
// Add JavaScript wrappers for WebContents class.
WebContents.prototype._init=function(){
constprefs=this.getLastWebPreferences()||{};
@@ -609,7 +615,27 @@ WebContents.prototype._init = function () {
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.