`app.setLoginItemSettings` documented arguments are misleading -- `path` and `args` should be passed in the `settings` object, not as separate params, like the code sample below it or in the test file here: 9250b559f9/spec/api-app-spec.js (L336)
and in the actual C++ function declaration here: f5a75c4e87/atom/browser/browser.h (L104)
Resolves#9139
For certain node command line options, those options can be set via the
process object (process.noDeprecation, process.throwDeprecation,
process.traceDeprecation, and process.traceProcessWarnings) so they are
documented here.
Also, sorted properties and methods alphabetically for easier
readability.
I found out that after trying to putting some long text in my extra properties that it was truncated, digging around I found these:
897d58bde1/atom/common/crash_reporter/crash_reporter_win.cc
const int kNameMaxLength = 64;
const int kValueMaxLength = 64;
Adds responders for `newWindowForTab` to `AtomApplicationDelegate` and
`NativeWindowMac`, so that `BrowserWindow`s with a `tabbingIdentifier`
will get the new tab button, and both `app` and `window` will emit a
`new-tab-for-window` event.
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`).
