* 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.
* fix: opt into location services once device service has been started
* refactor: provide fake location provider to mock geolocation reponses
* chore: add spec for navigator.geolocation api using fake location provider
Chromium commit [03563dd163][1] changed the way that the
spellcheck-enabled status was checked, defaulting to false.
Added the first (!) test for spellchecking, too.
Fixes#13608.
[1]: 03563dd163
There's an attempt to suppress the warning in `spec/static/main.js`, which
sets `process.env.ELECTRON_DISABLE_SECURITY_WARNINGS`. However, it sets the
variable too late in the boot process: by the time that line in main.js has
run, a child zygote has already been booted. `test.py` works around this by
setting that environment variable outside of the test process, to ensure that
it gets propagated to all children.
I've been running the GN tests directly with `./out/Default/electron
electron/spec`, rather than through the wrapper script, and the
`api-debugger-spec.js` tests were failing, because they depend on a particular
log message being the first one emitted, and the CSP warning was causing that
test to fail, since it wasn't being correctly suppressed.
Instead of writing another wrapper script, this just fixes the underlying thing
that the warning is complaining about, which I think is reasonable because the
test's pass/fail depends on this specific behaviour.
* 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 cause property to exception in callFunction
* update exceptionToMeta function
* add sender argument
* and cause property to return value
* update exception convert in metaToValue function
* add from and cause properties to the exception error
* unit test for remote exception
* Persist defaults to webPreferences object to JS land can read the inferred values instead of just user defined values
* Test inherited default propogation
* Refactor to remove coupling from fetching values and defaults
* Test description type
* Fix up tests
* 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
* 🔧 Add security issue detection (and logs)
* 🔧 Check for it on load
* 👷 Add some tests
* 👷 Make the linter happy
* 🔧 Allow them to be enabled by force
* 📝 Make message slightly prettier
* 🔧 Fix a typo in the code comment
* 🔧 Classic mistake
* 🚀 Optimize things a bit more
* 👷 Add tests, fix tests
* 📝 Document things
* 🔧 Make linter happy
* 🔧 One more piece of cleanup
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`).
- Use `path` module from browser process in sandboxed renderer. This is required
because the return value of `path.join` is platform-specific, and this is an
assumtion of crash-reporter.js which is shared between sandboxed and
non-sandboxed renderers.
- Set `process.platform` and `process.execPath` in sandboxed renderer
environment. This is required to spawn the windows crash service from
sandboxed renderer.
- Use a single temporary directory for all crashReporter tests. This is required
to make tests more deterministic across platforms(since mac's crashpad doesn't
support changing the crash dump directory). Also make a few improvements/fixes
to the `uploadToServer` test.
- Create a function that accepts BrowserWindow options and generates a suite
that contains the renderer-specific tests.
- Run the function twice to execute the tests with and without sandbox option.
See the fixed issue for the context. This pulls in a vendored copy of Node that includes the described patch.
Fixes#8358
Test Plan: Built Electron and verified it loaded the sample app correctly and that the module wrapper is the new one by viewing Node's source code in the Blink Inspector.
Added specs and tested with `npm test -- --grep "global variables"`
This adds the `disableguestresize` property for webviews to prevent the
webview guest from reacting to size changes of the webview element. This
also partially documents the `webContents.setSize` function in order to
manually control the webview guest size.
These two features can be combined to improve resize performance for
e.g. webviews that span the entire window. This greatly reduces the lag
described in #6905.
