There are use cases of webview where the container holding the webview is not
actually destroyed first, instead just webview gets removed from DOM, in such
situations the browser process map is not updated accordingly and holds reference
to stale guest contents, and any window operations like scroll, resize or keyboard
events that has to chain through browser embedder will lead to UAF crash.
Ref: https://github.com/microsoft/vscode/issues/92420
* docs: `newGuest` in `WebContents` and `webContents` in `BrowsweWindow`
According to the example codes in the documentation of `new-window`
event in `WebContents`, `webContents` in `BrowsweWindow` constructor
options and `newGuest` in `event` argument of `new-window` handler are
both existing but documented. This patch is for adding the related
documentations. Also, it provides typescript-definitations for these
two properties.
* Remove the documnent of `webContents` in BrowserWindow constructor option.
Prevent issues with menu creation and subsequent pane focus from menu bar by preventing menus from being created from an empty array. I can't conceive a valid use case for this, since if one wants to remove a menu they should be be passing null to win.setMenu() or calling win.removeMenu(). This issue is also specific to top-level menus, and not submenus, so the new check and exception is scoped to top-level menus.
* refactor: port window.open and window.opener to use ctx bridge instead of hole punching
* refactor: only run the isolated init bundle when webview is enabled
In some situations, we can't use auto update to communicate with our update server directly, and proxies can be tricky to get working. I spent a loooong time exploring a lot of options before coming across the comment I linked, so It thought it could be beneficial to people like me of the future.
* chore: bump chromium in DEPS to 461ecae368fd0832f18e0b13e61f3561d83f0031
* update patches
* update patches
* Remove both vs browser/child split in content gn files.
https://chromium-review.googlesource.com/c/chromium/src/+/2157965
* chore: bump chromium in DEPS to 7ff3897f3104563763ef26ad940d4e988d7245dd
* update patches
* update patches
* Add ElectronKioskDelegate for extensions
https://chromium-review.googlesource.com/c/chromium/src/+/2159760
Co-authored-by: John Kleinschmidt <jkleinsc@github.com>
Co-authored-by: Electron Bot <anonymous@electronjs.org>
* test: add pre-change snapshot of new-window event
* move to .ts file for easier diff
* refactor: improve feature string parsing logic
* test: update snapshots
* update type names per review
* update comma-separated parse test
* use for loop instead of reduce per review
* tighten up types
* avoid variable guest contents id returnValue in test snapshot
* fix moveAbove on Windows systems
The documentation for [setWindowPos](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowpos) second argument `hWndInsertAfter` is a bit confusing...
> A handle to the window to precede the positioned window in the Z order. This parameter must be a window handle or one of the following values.
Since Windows refers to the Z order from low to high it means that the window provided as reference will always _precede_ the electron window, which is the opposite of what we want in this function, since the electron window is displayed behind the referenced window.
The change is simply to ask `SetWindowPos` to position our window *behind* the window that's *above* the reference window, effectively making our window sit just above the reference one.
* lint
* fix: let setAppLogsPath write to disk on UI thread
Otherwise, the DCHECK in thread_restrictions will fire.
* scope the io allowance more tightly
* oops, scope it tightly in the mac version too
