* Initial changes to use crashpad for windows
* Remove crashpad patch
* Report error when failed to connect pipe
* Allow crashpad to communicate with named pipe
* Add patch to make crashpad named pipe work
* Windows also needs crashReporter on main process
* Call SetUnhandledExceptionFilter in node process
Node can also use crash reporter.
* Do not treat node process as browser process
* No more need to manually start crash service
* Use base::StringPrintf for better readbility
* Print error when pipe name not available
* Make sure pipe name is updated
Note that the crashpad may be started after renderer process gets
created.
* Fix some tests
* Update node
* Exclude crashpad files on Linux and MAS
* Fix lint warning
* Remove unused checks
* kCrashpadPipeName is only available on Windows
* Fix uploadToServer tests
* Fix extra params tests
* Fix getCrashesDirectory tests
* Run crashReporter tests on CI
* Style fixes
* Update crashreporter docs
* Rename InitBreakpad to Init
* Add comment for process_type_.empty() and UTF16ToASCII to UTF16ToUTF8.
* Update build.gn include crashpad headers
* Address comment https://github.com/electron/electron/pull/18483#discussion_r290887898
* Avoid using api::WebContents
* Put kRunAsNode in atom_constants
* Remove duplicate settings on upload params
* Fix building on macOS
* Update description for crashpad_pid_check.patch
Windows debug isn't logging because of a DCHECK failure during startup. This changes the logger initialization to use the absolute path, so that logging works again.
* chore: fix cpplint 'include_what_you_use' warnings
Typically by including <memory>, <utility> etc.
* chore: fix 'static/global string constant' warning
Use C style strings instead of std::string.
Style guide forbids non-trivial static / global variables. https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables
/home/charles/electron/electron-gn/src/electron/script/cpplint.js
* refactor: remove global string variables.
Fix 'global string variables are not permitted' linter warnings
by using the base::NoDestructor<> wrapper to make it explicit that
these variables are never destroyed.
The style guide's take on globals with nontrivial destructors:
https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables
* fix: initializer error introduced in last commit
* fix: remove WIP file that was included by accident
* fix: include order
* fix: include order
* fix: include order
* fix: include order, again
* enable plznavigate code path
* AtomBrowserClient::GetGeolocationApiKey returns the right default
* use IsLoadingToDifferentDocument to identify top level navigation in mainFrame
* use candidate site instance when available
* spec: don't test httpReferrer option for file origin
* update libcc ref
* affinity: only group same site in this mode
* plznavigate: don't emit did-get-response-details event for blob scheme
* remove unused variable
* limit scope of variable 'ret'
* pass shared_ptr<SkBitmap> by reference
* silence warning: value reassign before read
* fix oops
* don't refer to 'response' after std::move()ing it
* make the linter happy
When `--enable-sandbox` is passed, electron will use chromium sandbox to spawn
all renderers, and every new BrowserWindow will automatically have "sandboxed"
passed as a web preference(since the renderer would not work properly
otherwise).
When "sandboxed" is passed as a web preference for `BrowserWindow`, the newly
created renderer won't run any node.js code/integration, only communicating with
the system via the IPC API of the content module. This is a requirement for
running the renderer under chrome OS-level sandbox.
Beyond that, certain behaviors of AtomBrowserClient are modified when dealing
with sandboxed renderers:
- `OverrideSiteInstanceNavigation` no longer create a new `SiteInstance` for
every navigation. Instead, it reuses the source `SiteInstance` when not
navigating to a different site.
- `CanCreateWindow` will return true and allow javascript access.
