* test: move some BrowserWindow specs to the main process
* uncomment cross-site test
* move more tests
* re-enable, refactor and move visibilitychange specs
* move new-window event tests and re-enable them on mac
* move max/minimize event tests
* move modal tests
* move beginFrameSubscription tests
* move savePage test
* move BrowserWindow options argument is optional test
* move restore, unmaximize, fullscreen tests
* move parent window tests
* don't wait for show event on windows (#8664)
* add debugging logs to fullscreen tests
* more debugging on windows
* explicitly destroy browserviews to prevent crash during gc
* only await show on darwin
* more event timing fixes
* disable max/minimize event tests on linux, since they're broken on CI
* chore: update to node 12.4.0
* chore: fix js2c compilation and usage
* update branch reference
* chore: roll node
* refactor: use the new node::options_parser::Parse method
* fix: make node create our context for us so that everything is initialized correctly
* fix: let node do it's thing to the all contexts
We need to let node know about all the contexts that Chromium creates for the renderer processes so that it does not crash when trying to access primordials. Similar to node::NewContext but with an existing context
* chore: roll node
* chore: roll node
* chore: roll node
* chore: roll node
* fix: ensure that _noBrowserGlobals is set before the node bootstrapper runs
Co-authored-by: Jeremy Apthorp <jeremya@chromium.org>
Resolves#18805.
We want to keep default move conflict handling behavior in that it's still what most users would expect, but there exist edge cases in which users may not want to be forced into that behavior.
This thus introduces an optional conflict handler that allows developers access to more granular move actions. They could now allow the user to choose whether to delete an existing app in favor of the current one being moved, or whether to quit the current app and focus on the existing one should it both exist and be running. I added a fair amount of new documentation outlining this behavior, but if there are things users may benefit from seeing examples of or nuances that should be added please leave feedback!
This adds the NSRequiresAquaSystemAppearance key to our default Info.plist file which will tell macOS to auto-switch our effectiveAppearance in sync with the OS. The dark mode documentation has been updated to reflect how to opt *out* of this but it is also noted that certain dark mode APIs will not work on Catalina if you opt out.
The wiring to update prefs when you toggle between dark mode and light mode exists in the content layer but the actual value setting is done in either //chrome or in shell. We need to set the preferred_color_scheme pref value in order for the CSS query to work correctly. The DarkModeObserver in content will automatically regenerate prefs when dark mode is toggled.
Fixes#15540
For now it only adds the ability to place the window below
the task bar while still being always on top.
Previous behaviour was always showing the window above the task
bar when top is true. We keep this default behaviour, i.e. when
the 'level' parameter is omitted.
https://github.com/electron/electron/issues/18933
Notes: Can set a window always on top but behind the taskbar on Windows
* fix: use gn/clang-format from src
* fix: download clang-format in lint job
* chore: fix linting warning
* chore: get_path_in_buildtools => get_buildtools_executable
* chore: the clang-format npm package is not used
* chore: bump chromium in DEPS to c87ad34dfd48610959977db9b6eeeb86f5feafe9
* chore: rebase patches
* chore: bump chromium in DEPS to ad29fca14d77b2a1752f24d9425278c6737c0f70
* chore: bump chromium in DEPS to 22c21a9cc728e7958e3ac1033cfdc6ed0f0a8b10
* chore: bump chromium in DEPS to 8c86dd7f76abf4ad1ab41796d2da6172b1b10866
* chore: update patches
* chore: bump chromium in DEPS to 5a48e127c8cb8ae827f4fead0b527079194b9899
* remove TransformPointToLocalCoordSpaceLegacy
https://chromium-review.googlesource.com/c/chromium/src/+/1637525
It was not implemented on Mac despite being available as a constructor
option. Implementation already exists on Windows. Linux case can be
separately.
https://github.com/electron/electron/issues/19032
Notes: Implemented BrowserWindow.setFocusable on macOS.
