* 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`).
