* test: move more BrowserWindow specs to main runner
* more movey
* maximized/minimized events don't work on linux?
* try for better printing of non-equal bounds
* add a timeout when checking window bounds after resize
* add a timeout when reading content size
* setTimeout...?
* try a smaller window size
* chore: add debounce on the updateWebContentsVisibility method to ensure quick changes in occlusion do not result in flickering
* chore: update old patch headers
* chore: add ability to log native deprecation warnings
* take std::string, handle conversion later
* address feedback from @ckerr's review
* simplify with feedback from zcbenz
When we blast off again, we check out a commit so the current branch ends up being incorrect and is HEAD rather than X-Y-Z. This therefore no longer just runs git rev-parse --abbrev-ref HEAD; it instead checks to ensure that the result of that call matches the release branch pattern. If it doesn't, it fetches the containing branch for the commit.
Since we only ever blast off from bump commits, we can safely assume that only one release branch will ever contain the bump commit and therefore be the one we want to use when tagging the release on npm.
Legacy print statements are syntax errors in Python 3 but print() function works as expected in both Python 2 and Python 3.
Old style exceptions are syntax errors in Python 3 but new style exceptions work as expected in both Python 2 and Python 3.
The `flatten` option has been removed from electron-windows-store dcc654df2e so running the command would produce an error:
> error: unknwon option --flatten
* build: show ninja stats for testing/debug builds
* Update .circleci/config.yml
Co-Authored-By: Jeremy Apthorp <nornagon@nornagon.net>
* Use regular depot tools instead of third party one
* I forget where depot tools lives
* Fix depot tools path
This is useful for checking which processes are sandboxed on OS level.
Regarding creationTime, since the pid can be reused after a process dies, it is useful to use both the pid and the creationTime to uniquely identify a process.
Historically, we've been passing in all MessageBox parameters individually, which makes augmenting or improving MessageBox functionality challenging because to change or add even one argument requires a huge cascade of argument changes that leaves room for errors.
For other file dialog related APIs, we use a struct (DialogSettings), and so this PR takes a similar approach and refactors MessageBox parameters into a struct (MessageBoxSettings) which we then use to simplify argument passing and which will enable us to more quickly iterate and improve upon functionality in the future.
