It was implemented on Mac and Win but not on X11.
Tested on Ubuntu 16.04 and 18.04.
Also added a unit test in spec/api-browser-window-spec.js.
This test BrowserWindow.moveTop verifies that calling moveTop
on a window does not give the focus to this window.
notes: BrowserWindow.moveTop is now available on Linux/x11
https://github.com/electron/electron/issues/12516
* feat: add support for node / preloads in subframes
This feature has delibrately been built / implemented in such a way
that it has minimum impact on existing apps / code-paths.
Without enabling the new "nodeSupportInSubFrames" option basically none of this
new code will be hit.
The things that I believe need extra scrutiny are:
* Introduction of `event.reply` for IPC events and usage of `event.reply` instead of `event.sender.send()`
* Usage of `node::FreeEnvironment(env)` when the new option is enabled in order to avoid memory leaks. I have tested this quite a bit and haven't managed to cause a crash but it is still feature flagged behind the "nodeSupportInSubFrames" flag to avoid potential impact.
Closes#10569Closes#10401Closes#11868Closes#12505Closes#14035
* feat: add support preloads in subframes for sandboxed renderers
* spec: add tests for new nodeSupportInSubFrames option
* spec: fix specs for .reply and ._replyInternal for internal messages
* chore: revert change to use flag instead of environment set size
* chore: clean up subframe impl
* chore: apply suggestions from code review
Co-Authored-By: MarshallOfSound <samuel.r.attard@gmail.com>
* chore: clean up reply usage
* chore: fix TS docs generation
* chore: cleanup after rebase
* chore: rename wrap to add in event fns
HEX with alpha can be #RRGGBBAA or #AARRGGBB. In Electron it's the latter. It's nice to explicitly state that, so others wont have to try twice like me :).
* feat: add multi BrowserView support to BrowserWindow
Add functions addBrowserView, removeBroserView, getBrowserViews to
BrowserWindow class. Existing API as setBrowserView and
getBrowserView code replaced to use new api inside.
* fix: for lint and osx compile errors
* fix: lint error in test code
* feat: add multi BrowserView support to BrowserWindow
Add functions addBrowserView, removeBroserView, getBrowserViews to
BrowserWindow class. Existing API as setBrowserView and
getBrowserView code replaced to use new api inside.
* fix: for lint and osx compile errors
* fix: lint error in test code
* fix: method to be accessible on mac api impl
* fix: missed function declarations for mac impl
* fix: use base class reset function
* Added mouse forward/back button support on Linux
* Added browser history navigation action bindings for Windows, Mac, and Linux keyboard
* Removed new `history-action` event and modified `app-command` to execute on such events
* Removed attempt at macOS support and added constants
* Clarified app-command documentation
* Reverted 'app-command' description change
* Format code
Extend the existing win.setBounds functionality by allowing developers to partially update bounds without being forced to pass in all four bounds values. No existing functionality is altere
* fix: child window with nativeWindowOpen should disable node integration
* Revert "fix: do not enable node integration in child window if not enabled (#15076)"
This reverts commit 0252d7686c.
This patch is not needed anymore since we are force disabling node integration
for child windows.
* Inital setSize check
* Only resize if above minimum size constraints
* lint
* Resize to min if size is changed
* Remove unneeded if statement
* chore: remove trailing whitespace
* Add note about setSize method in docs
* feat: add evt listeners for SetAlwaysOnTop
* only emit one event on AlwaysOnTop change
* docs: add new alwaysontop event
* dont emit if theres no change
* address feedback from review
* First commit
* Add Mac support (1st attempt)
* Add Mac support (2nd attempt)
* Simplify tests
* Restore window state !
* Looking at other tests, seems minimize, maximize, fullscreen are skipped when in CI
* Fix Mac tests
* Restore tests in CI
* Fix typo
* widget getRestoredBounds not working on Mac !!
* widget getRestoredBounds not working on Mac !!
* Add IsNormal function
* Add IsNormal
* IsNormal => isNormal
* Deactivate fullscreen on Mac. Do not receive leave-fullscreen event
* Set default original_frame_
* Set default original_frame_
* Fix Mac
This binds Widget::SetShape, an API that already exists in Chromium (for
Windows and Linux). It's a more reliable method of having some parts of
your window be "click-through" than the current `setIgnoreMouseEvents`
API, which messes around with the `WS_EX_LAYERED` window style on
Windows, causing strange bugs and incompatibility with hardware
acceleration.
The new `will-resize` event can be used to prevent the resize from
happening before the native window is actually resized. This is in
contrast to the existing the `resize` event, which is sent *after* the
native window has already been resized. For apps with e.g. custom window
snapping logic, the `resize` event is not sufficient because it will
result in flickering between the dragged size and the snapped size.
`will-resize` is only emitted on macOS and Windows.
Fixes#12701 and supersedes #13131.
Ideally we would have added `setTitleBarStyle()`, but that is a
significantly more involved change. For example, consider the case where
we switch from `hidden` to `normal`. We would not only have to show the
traffic light buttons, we would also have to switch the window from a
frameless to a framed window and deal with various other window state.
Lets instead implement a simple solution for #12701.
* Propagate referrer to new windows
Fixes#9205
* Rearrange -new-window event arguments for backwards-compatibility
* Plumb referrer policy through guest-window-manager
* Document the Referrer structure and its uses
* Add tests for referrer in new windows
* Docs nits
* update doc for setProgressBar
The linter was unable to get `paused` as a possible value for `mode`
* update doc for setProgressBar
Addressing PR feedback
* Only set title bar to transparent when vibrant with a custom titlebar
* Correctly set the transparent state of the GpuSwitcher so vibrancy works on reload
* Document case where using frame: false without custom titleBarStyle and vibrant
* This is to enable more browser-like behavior so that users who run third-party code
will not be DOS'ed with alerts and confirms. This is already handled like this
in most major browsers so this will greatly help these developers
* Fix URLs and Paths in docs/
* Avoiding link break to /docs/development/updgrading-chrome.md
* Fix URLs and Paths in docs/ #2
* Removed double spaces in docs
Adds responders for `newWindowForTab` to `AtomApplicationDelegate` and
`NativeWindowMac`, so that `BrowserWindow`s with a `tabbingIdentifier`
will get the new tab button, and both `app` and `window` will emit a
`new-tab-for-window` event.
Chromium already includes the necessary plumbing to manage the
visibility properties and `visibilitychange` event so this gets rid of
most of our custom logic for `BrowserWindow` and `BrowserView`.
Note that `webview` remains unchanged and is still affected by the issues
listed below.
User facing changes:
- The `document` visibility properties and `visibilitychange` event are
now also updated/fired in response to occlusion changes on macOS. In
other words, `document.visibilityState` will now be `hidden` on macOS
if the window is occluded by another window.
- Previously, `visibilitychange` was also fired by *both* Electron and
Chromium in some cases (e.g. when hiding the window). Now it is only
fired by Chromium so you no longer get duplicate events.
- The visiblity state of `BrowserWindow`s created with `{ show: false }`
is now initially `visible` until the window is shown and hidden.
- The visibility state of `BrowserWindow`s with `backgroundThrottling`
disabled is now permanently `visible`.
This should also fix#6860 (but not for `webview`).
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
