Merging conflicts:
038f367c30
After this roll, we no longer require our custom `onFrameLocationChanged` instrumentation
since gecko now fixed the `NOTIFY_LOCATION` behavior so that it works
for same-document navigations inside iframes.
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.
browser(firefox): ensure detachedFromTarget is always sent
LinkedBrowser can throw when removing listeners in PageTarget.dispose,
and that prevents BrowserHandler from sending Browser.detachedFromTarget.
Using a try-catch seems good enough.
Currently, browser.version() returns `83.0`, whereas launching firefox
with `--version` flag returns `83.0b3`. This patch alings protocol's
`Browser.version()` with flag output.
Somehow, we get WebProgress state changes when worker is loaded
with a blob url. This messes up frame navigation detection.
Luckily, it's easy to filter out non-document state changes.
