* feat: deprecate default value of nodeIntegration
* Use DeprecationStatus::Stable as the default instead of shadowing
* change wording of deprecations
* chore: also deprecate kWebviewTag and kContextIsolation
* chore: do as we preach, lets be secure-by-default in the default app
Replaces 'did-finish-load' with 'did-stop-loading' which semantically
maps to the events inside Chromium. Before I think we were relying
on a natural 99% winnable race condition.
Fixes#13504
* Add promise helper and change whenReady to be native impl
* remove commented code
* add GetInner helper to dedupe promise code
* add Promise.reject helper to be consistent with JS
* fix linting
* update promise impl per feedback
* remove param name from unused isolate
* Use non-depreceated resolvers for promises
* Add thread dchecks for promise helper, intiialize promise pointer to nullptr
* Introduce `net.{start|stop}Logging()`
- Slight regression right now as Electron won't automatically start logging net-logs at launch, will soon be fixed
- To implement callback for async controls
* Add `net.isLogging` & optional callback param for `net.stopLogging()`
* Fix small regression on --log-net-log
--log-net-log should work again
* Error on empty file path
* Only start with valid file path
* Remove unused var
* Allow setting log file path before URLRequestContextGetter starts logging
* Add net log tests
* Remove redundant checks
* Use brightray::NetLog
* Clean up code
* Should automatically stop listening
* 🎨 Attempt to fix styles
* Only run non-null callback
* Dump file to tmpdir
* Simplify net log spec
Spawned Electron process on Linux CI can fail to launch
* Separate netLog module
* Remove net logging test from net spec
* Add tests for netLog
* Fix header guard
* Clean up code
* Add netLog.currentlyLoggingPath
* Callback with filepath
* Add test for case when only .stopLogging() is called
* Add docs
* Reintroduce error on invalid arg
* Update copyright
* Update error message
* Juggle file path string types
* Don't use JSON to send the result of `ipcRenderer.sendSync`.
- Change the return type of AtomViewHostMsg_Message_Sync from `base::string16`
to `base::ListValue`
- Adjust lib/browser/api/web-contents.js and /lib/renderer/api/ipc-renderer.js
to wrap/unwrap return values to/from array, instead of
serializing/deserializing JSON.
This change can greatly improve `ipcRenderer.sendSync` calls where the return
value contains Buffer instances, because those are converted to Array before
being serialized to JSON(which has no efficient way of representing byte
arrays).
A simple benchmark where remote.require('fs') was used to read a 16mb file got
at least 5x faster, not to mention it used a lot less memory. This difference
tends increases with larger buffers.
* Don't base64 encode Buffers
* Don't allocate V8ValueConverter on the heap
* Replace hidden global.sandbox with NodeBindings::IsInitialized()
* Refactoring: check NodeBindings::IsInitialized() in V8ValueConverter
* Refactor problematic test to make it more reliable
* Add tests for NaN and Infinity
* Refactor app.makeSingleInstance
* new API `app.isPrimaryInstance()`
* new API `app.isSingleInstance()`
* new event `app.on('second-instance')`
* deprecated old syntax `app.makeSingleInstance(cb)`
* deprecated old syntax of `app.makeSingleInstance() --> bool` in favor
of `app.isPrimaryInstance()`
* Fix spec, we don't need process.nextTick hacks any more
* Make deprecation TODO for the return value of makeSingleInstance
* Refactor makeSingleInstance to requestSingleInstanceLock and add appropriate deprecation comments
* I swear this isn't tricking the linter
* Make const
* Add deprecation warnings for release, and add to planned-breaking-changes
BREAKING CHANGE
Add four new optional properties to menus in Electron. The four properties are:
'before'
'after'
'beforeGroupContaining'
'afterGroupContaining'
'before/after' - provides a means for a single context menu item to declare its placement relative to another context menu item. These also imply that menu item in question should be placed in the same “group” as the item.
'beforeGroupContaining/afterGroupContaining - provides a means for a single menu item to declare the placement of its containing group, relative to the containing group of the specified item.
* 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
Fixes#12311
Right now it throws a new error when the file is even require()d, but this isn't ideal as there are cases where everything is mass-required, such as Spectron. Instead, we should throw an error on non-Darwin environments only when the IAP methods are invoked.
* Fix child touch bar items not updating
Deep children of a TouchBar didn't cause the top level touch bar to update, now they do
Fixes#11761.
* Remove unused newValue property in TB setter
* add function to remove leading/trailing separators
* change const name for clarity
* add spec to check filtered separators
* clean method and add edge case spec per review
The event is emitted when the OS is rebooting/shutting down, and allows
an electron app to call `e.preventDefault()` in order to delay shutdown
and exit cleanly.
- For more flexibility in designing the recent documents menu, now there can be one menu item (known issue: you may specify more but AppKit doens't display more than one) in the submenu list, rather than separating the labels with a tab.
- Also added is the role `clearrecent` that can be given to a menu item that can clear the recent documents.
- Does not yet accept any options except label--"Clear Menu" can't be modified through exposed node API
- If `openrecent` is present across multiple menu items, the last seen will be visible in the main menu due to that it is designed to behave like a singleton
When a link is clicked with the middle mouse button, chrome opens a window with
"background-tab" disposition. This is not currently handled in sandbox mode,
causing an api::WebContents to leak leading to eventual crash(since it has no
wrapper).
Also fix the event handler for "-add-new-contents" by having it call
`event.preventDefault()` when the window creation should be cancelled.
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`).
Current implementation of NavigationController does not allow using
`history.pushState()` if page url is not changed.
It worked by mistake in versions < 1.3.6 and got visible after fix 180a77e6.
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.
