* docs: add references to app.whenReady() in isReady
* refactor: prefer app.whenReady()
In the docs, specs, and lib, replace instances of `app.once('ready')`
(seen occasionally) and `app.on('ready')` (extremely common) with
`app.whenReady()`.
It's better to encourage users to use whenReady():
1. it handles the edge case of registering for 'ready' after it's fired
2. it avoids the minor wart of leaving an active listener alive for
an event that wll never fire again
* fix: menu visibility should not be overwritten on startup
* fix: removing menu for window without global menubar
* test: setMenu tests are not for mac
* refactor: bundle the browser and renderer process electron code
* Bundles browser/init and renderer/init
* Improves load performance of main process by ~40%
* Improves load performance of renderer process by ~30%
* Prevents users from importing our "requiring" our internal logic such
as ipc-main-internal. This makes those message buses safer as they are
less accessible, there is still some more work to be done though to lock
down those buses completely.
* The electron.asar file now only contains 2 files, as a future
improvement maybe we can use atom_natives to ship these two files
embedded in the binary
* This also removes our dependency on browserify which had some strange
edge cases that caused us to have to hack around require-order and
stopped us using certain ES6/7 features we should have been able to use
(async / await in some files in the sandboxed renderer init script)
TLDR: Things are faster and better :)
* fix: I really do not want to talk about it
* chore: add performance improvements from debugging
* fix: resolve the provided path so webpack thinks it is absolute
* chore: fixup per PR review
* fix: use webpacks ProvidePlugin to keep global, process and Buffer alive after deletion from global scope for use in internal code
* fix: bundle worker/init as well to make node-in-workers work
* chore: update wording as per feedback
* chore: make the timers hack work when yarn is not used
By default the Chromedriver will send remote-debugging-port=0 to let the
browser choose a free port to listen on. The chosen port is written to
a known file in the user data dir that is passed to the app through the
CLI.
This PR does two things.
1. Correctly passes the USER_DATA_DIR to the remote debugging server so
it knows where to write the file
2. Adds support for --user-data-dir as we did not support that CLI
argument and Chromedriver relies on being able to tell the "browser"
where to write this file.
Fixes#17354
