* [ci skip] refactor: create request context from network context
* [ci skip] refactor: subscribe to mojo cookiemanager for cookie changes
* [ci skip] refactor: manage the lifetime of custom URLRequestJobFactory
* refactor: use OOP mojo proxy resolver
* revert: add support for kIgnoreCertificateErrorsSPKIList
* build: provide service manifest overlays for content services
* chore: gn format
* fix: log-net-log switch not working as expected
* spec: verify proxy settings are respected from pac script with session.setProxy
* chore: use chrome constants where possible
* fix: initialize request context for global cert fetcher
* refactor: fix destruction of request context getters
* spec: use custom session for proxy tests
* fix: queue up additional stop callbacks while net log is being stopped
* fix: Add CHECK for cookie manager retrieval
* chore: add helper to retrieve logging state for net log module
* fix: ui::ResourceBundle::GetRawDataResourceForScale => GetRawDataResource
* style: comment unused parameters
* build: move //components/certificate_transparency deps from //brightray
* chore: update gritsettings_resource_ids patch
* chore: update api for chromium 68
* fix: net log instance is now a property of session
* fix: use render client id to track deleted render process hosts
Instead of relying on OS process id, which may not be unique
when a process is reused, we rely on the renderer client id
passed by the content layer when starting the renderer process
which is guaranteed to be unique for the lifetime of the app.
* fix: store context id as int64_t
Ensuring that it doesn't wrap easily with a large number
of context creation on some malformed web pages.
RenderProcessHost switch can happen between ipc calls when
speculative process are invvolved, which will lead to deletion
of entries on current context. Use OS process handles to
uniquely associate a destruction handler for a render process.
* 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
* Fix timing issue in singleton fixture.
Singleton now sends the "we've started" message out only after it's
received a `'ready'` event from `app`. Previously it sent the message
out immediately, resulting in the parent test trying to manipulate it
before Singleton's event loop was fully bootstrapped.
* Check for graceful exits on Linux, too.
Rewrite the "exits gracefully on macos" spec to run on Linux too.
* Check for graceful exits everywhere.
* Tweak comment
* Better error logging in api-app-spec.js. (#12122)
In the 'exits gracefully' test for app.exit(exitCode),
print the relevant error information if the test fails.
* Run the exit-gracefully test on macOS and Linux.
Windows does not support sending signals, but Node.js offers some
emulation with process.kill(), and subprocess.kill(). Sending signal 0
can be used to test for the existence of a process. Sending SIGINT,
SIGTERM, and SIGKILL cause the unconditional termination of the target
process.
So, we'll need a different approach if we want to test this in win32.
* infrastructure for setLocale via klang
* add documentation for setLocale
* add test for setLocale
* fix spec
* add spec and update docs
* fix carriage feeds on windows
* SetLocale() sets LC_ALL on Linux
* in SetLocale() on Linux, use g_setenv()
* fix tyop: '#ifdef OSX_POSIX'
* make the linter happy
* improvements from review
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`).
