Electron's `AtomNSWindow` implements `accessibilityAttributeValue` to
provide various accessibility info to the OS, including window titles.
Chromium 75 changed to Apple's newer accessibility API for window titles
in the super class that `AtomNSWindow` inherits from. macOS still
supports both the old and new style APIs, but it will prefer the new
style if it is implemented. This means the Electron window title is
being ignored because the newer API at the Chromium level has taken
precedence.
By implementing the newer accessibility API in `AtomNSWindow`, this
restores correct accessibility window titles in macOS Electron apps.
This is a regression has been present since Electron 6.0.0 (the first
release including the Chromium change above).
* fix: menu visibility should not be overwritten on startup
* fix: removing menu for window without global menubar
* test: setMenu tests are not for mac
* docs: improve Windows build variable documentation
Documents an additional and possibly unclear variable, `DRIVE:`, in the example global variables for building with Windows
* docs: update formatting in build-instructions-windows.md to align with styleguide
In #20829, we fixed compositor recycling when switching between
BrowserViews, but it turns out that there is one additional case that we
need to handle. When we create a completely new BrowserView instance, it
starts of as visible (even when it hasn't been added to the window),
which means that it will need its own compositor instead of using the
recycled compositor.
To fix this, lets make BrowserViews hidden by default until they're
added to the window. See also #19988. This is a potentially breaking
change given that the initial value of `document.visibilityState` will
now be `hidden`, but given the experimental status of BrowserViews, I
think this is a fine change to make. The old behavior can be restored
with `webPreferences: { show: true }`.
Notes: Fix compositor recycling when creating new BrowserView
* build: cache the out directory for exact deps hash matches
* chore: generate a target based depshash discriminator
* fix: hash on gn args
* build: share logic on the mac builds
* build: ensure that the mksnapshot binary is built before stripping before zipping
* build: attach the workspace on macOS
* build: optimize the macOS checkout path for testing
* build: fix mksnapshot zip generation
* build: make the mac src cache restore work
* build: v2 out cache
* build: macOS cache restore is just stupidly slow
* build: strip more binaries
* build: attach the out cache to the workspace for macOS builds
* build: allow linux boxes to restore darwin out caches
* build: cat the deps hash target file
* build: ensure that the deps target hash matches on the linux box
* build: do not use host arch in target key
* build: force undefined in the target hash file
* build: only restore out cache when it isn't in the workspace
* build: fix the macOS cache workspace trick
* build: do not double restore
* build: remove the big stuff from the out dir
* build: workaround layer issue
* build: try it back on macOS again but with smaller thingy
* build: macOS needs the out cache now
* build: clean up for omptimal macOS path
* build: use old docker image
* build: idek at this point
* build: we need a deps hash
* build: yeah we need a checkout too
* chore: use testing env on save cache job
* chore: well that should fix the cache key thing
* chore: handle cross-OS path mismatch for src cache restore
* build: use a /portal directory to transfer the src cache appropriately
* build: use the correct docker image
* build: super perms for /portal
* build: increment out cache number
* build: ensure target hash is correct for args + disable pre-compiled headers on macOS
* build: wipe the cross-arch libffmpeg before building Electron
