This way bash won't expand and post-process variable values in any way.
The changes are driven with
[`shellcheck`](https://github.com/koalaman/shellcheck)
Browsers require particular xcode versions to be installed on the host
machine to produce successful build.
This patch starts using explicit xcode versions for all mac browser
builds.
Before that it actually didn't install all needed dependencies and failed after that when starting the compiler suite. WebKit also installs dependencies with apt, so it should be fine to install them on OS level.
browser(firefox): properly initialize debugging pipe on windows
Firefox on Windows has 2 launch modes:
- default: a special "launcher process" is used to start browser as a
sub-process
- non-default: browser process starts right away
Firefox has a logic to detect how successful was the use of the
launcher process to do self-recovery when things go wrong. Namely:
- when attempting to use launcher process, firefox records a timestamp
of the attempt beginning
- once the launcher process successfully launches browser sub-process,
firefox records another timestamp of the completion
On a new launch, firefox checks what timestamps are present. If there's
a timestamp that signifies start of launcher process, but no successful
timestamp, it decides that last "launcher process" use was not
successful and falls back to launching browser right away.
When launching 2 firefox processes right away, the first process
uses attempts to use launcher process and records the first timestamp.
At the same time, the second instance sees the first timestamp and
doesn't see the second timestamp, and falls back to launching browser
right away. Our debugging pipe code, however, does not support
non-launcher-process code path.
This patch adds support for remote debugging pipe in case of
non-launcher-process startup.
Drive-by:
- disable crashreporter altogether
- remove stray dcheck that breaks firefox debug compilation
- disable compilation of firefox update agent
- do not use WIN32_DISTRIB flag unless doing full builds since
it kills incremental compilation
References #4660
**Preamble**
1. We're trying to setup a windows-based github self-hosted runner in the
playwright-internal repo.
1. Commands on Windows are mandated to have total arguments length
less then 32767 characters.
1. On windows, github self-hosted runner framework puts repository
checkout at `c:\w\playwright-internal\playwright-internal`
1. Our scripts create a checkout at
`c:\w\playwright-internal\playwright-internal\browser_patches\firefox\checkout`
1. One of the scripts in Firefox buildsystem tries to execute a command,
passing lots of absolute paths to various webidl's
1. The command fails due to restriction in (2)
**Problem**
Firefox build fails since checkout is deeply nested and hits max arg
size on windows.
**Solution**
This patch introduces a new variable `FF_CHECKOUT_PATH` that is
respected by all browser-related scripts. This way we'll be able
to checkout firefox to `c:\firefox` and avoid hitting long arguments
limit.
The `$PROGRAMFILES` variable is defined per the bitness of the
application: 32-bit shells get `C:\Program Files (x86)`, whereas
64-bit shells get `C:\Program Files`.
Visual Studio, however, has only 32-bit build and is always located in
the `C:\Program Files (x86)` folder.
This patch fixes `//browser_patches/firefox/build.sh` on 64-bit windows
shell.
Otherwise if required version is not installed the build fails with a cryptic message like
`error: toolchain '1.45.0-x86_64-unknown-linux-gnu' does not support components`
Firefox buildchain does not fixate `rust` and `cbindgen` versions,
so we want to fixate them on our end.
A table with matching rust version for every firefox version can
be found at [Rust Update Policy for Firefox](https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox).
Additionally, there are checks in `mozbuild` for the minimum
rust version and minimum `cbindgen` version.
This strictly defines Firefox build folder as `obj-build-playwright`.
Currently, Firefox build folder encodes current Mac OS version including
patch versions, and thus we might end up with multiple different build
folders.
