desktopCapture.getSources() returns a promise which should resolve
when capturing finishes. Internally it creates an instance of
DesktopCapturer which is responsible for resolving or rejecting
the promise.
Between the time DesktopCapturer starts capturing frames and when
it finishes, it's possible for its handle to be GC'd leading to
it never resolving.
These changes pin the instance of DesktopCapturer until it either
finishes or errors.
fixes#25595
Co-authored-by: samuelmaddock <samuel.maddock@gmail.com>
Move it from LoadURL to RenderViewCreated which is present
in all window creation cases and is called early enough to be
relevant from user prespective and after RenderWidgetHostView
is already present.
Co-authored-by: marekharanczyk <48673767+marekharanczyk@users.noreply.github.com>
* feat: add `win.setTopBrowserView()` so that BrowserViews can be raised (#27007)
* feat: Raise a browser view via `BrowserWindow.setTopBrowserView()`.
This is similar to removing and re-adding a browser view, but avoids a visible flicker as the browser view is not removed from the window when using `setTopBrowserView`. Note: if the given browser view is not attached to the window, it will be added.
This commit contains the macOS implementation.
* feat: setTopBrowserView support for Windows and Linux
* docs: add info about setTopBrowserView
* docs: Clarify behavior when browserView is not yet attached.
* fix: throw en error when browserView is not attached to the window
* fix: build error
* fix: test
* fix: add test case
* fix: tests
* fix: reparenting
* fix: close second window in tests
Co-authored-by: sentialx <sentialx@gmail.com>
* fix: build error
Co-authored-by: Stewart Lord <stew@offbynone.com>
* Use std::forward_list instead of base::LinkedList for better perf,
more consistent memory management. Better than std::list because we
don't need the double-linked-list behavior of std::list
* Use std::unordered_map instead of std::map for the v8 hash table
Co-authored-by: Samuel Attard <sattard@slack-corp.com>
base::LinkedList does not delete its members on destruction. We need to
manually ensure the linkedlist is empty when the ObjectCache is
destroyed.
Fixes#27039
Notes: Fixed memory leak when sending non-primitives over the context
bridge
Co-authored-by: Samuel Attard <sattard@slack-corp.com>
The call stack for one of our top crashes looks like this:
```
node::Abort (node_errors.cc:241)
node::Assert (node_errors.cc:256)
node::MakeCallback (callback.cc:226)
gin_helper::internal::CallMethodWithArgs (event_emitter_caller.cc:23)
gin_helper::EmitEvent<T> (event_emitter_caller.h:51)
gin_helper::EventEmitterMixin<T>::Emit<T> (event_emitter_mixin.h:81)
electron::api::DownloadItem::OnDownloadUpdated (electron_api_download_item.cc:115)
download::DownloadItemImpl::UpdateObservers (download_item_impl.cc:482)
content::DownloadManagerImpl::Shutdown (download_manager_impl.cc:508)
content::BrowserContext::~BrowserContext (browser_context.cc:476)
```
Full stack here: https://sentry.io/share/issue/9b030a0601b547188181b543c16ecda2/
During browser shutdown, the `DownloadManager` was being cleaned up
*after* the Node environment had already been destroyed. This caused the
`DownloadItem::OnDownloadUpdated` callback to crash when trying to emit
the JS `done` event.
To prevent this, we now manually shut down the `DownloadManager`
earlier. This is also mentioned in the comment on
`DownloadManager::Shutdown`:
```
// Shutdown the download manager. Content calls this when BrowserContext is
// being destructed. If the embedder needs this to be called earlier, it can
// call it. In that case, the delegate's Shutdown() method will only be called
// once.
```
Co-authored-by: Biru Mohanathas <birunthan@mohanathas.com>
* fix: prevent crash when destroyed widget receives keyboard event
Activating a key to close a window will cause a silent crash. Handling the keyboard
event will lead to a nullptr dereferenced in Chromium code if the window widget has
already been destroyed.
* test: ensure BrowserWindow doesn't crash from keyboard events during close
Co-authored-by: samuelmaddock <samuel.maddock@gmail.com>
