This moves default Firefox and WebKit checkouts to $HOME folder,
unless browser specific env variables are specified.
In other words:
- Firefox checkouts goes to `$HOME/firefox` unless there's a
`$FF_CHECKOUT_PATH` that specifies a custom location.
- WebKit checkout goes to `$HOME/webkit` unless there's a
`$WK_CHECKOUT_PATH` that specifies a custom location.
With this change, all build bots will now re-use checkouts
between builds, which should speed up compilation.
Apple M1 builders are now updated to the BigSur 11.6.
This patch:
- changes build assertions to validate 11.6 operating system
- changes build archive name to have major version only
- updates `//src/utils/registry.ts` to a new archive name for M1
This affects only M1 builds for Firefox, Firefox-Beta & WebKit.
We should roll these browsers at least once before 1.16 release.
Broken since https://github.com/microsoft/playwright/pull/8049
Previously when doing `build.sh --full` it was installing deps + building. Currently when passing `--full` it does not install the deps before, since it tries to compile before.
Instead of building firefox using `//browser_patches/buid.sh ff-beta`,
one can use `//browser_patches/repack-juggler.mjs ff-beta`.
The script will download the last Playwright build, and repack
Juggler and preferences there.
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.
When Firefox decides to perform an http->https redirect based on HSTS
information, it issues an "internal" redirect and cancels the http request.
Since there is no response for the http request, we forge 307 redirect
in this case, following Chromium lead.
The relevant code is in nsHttpChannel::StartRedirectChannelToHttps.
With this change, the script is now 2-stage:
- first, prepare browser build with `repack-juggler.js --prepare`
- afterwards, run the script to repack tot juggler version with the
bubild
This patch adds a new script -
`//browser_patches/firefox/repack-juggler.mjs`
This script lets you test Firefox changes if they are Juggler-specific
without firefox checkout / compilation.
The `repack-juggler.mjs` script does the following:
- downloads the latest build of Firefox-with-juggler
- finds an `omni.ja` file with Juggler files inside
- replaces juggler in omni.ja with the current juggler files in the index
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.
- to read post data of requests, we have to read stream
- to restore the stream later on, we have to rewind it back
- however, if the stream is large enough, it cannot be rewound back
This patch starts cloning post data streams if possible to avoid
back-rewinding them later on.
References #4704
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.
As Joel noticed recently, MessageManager in firefox doesn't guarantee
message delivery if the opposite end hasn't been initialized yet. In
this case, message will be silently dropped on the ground.
To fix this, we establish a handshake in SimpleChannel to make sure that
both ends are initialized, end buffer outgoing messages until this
happens.
Drive-by: serialize dialog events to only deliver *after* the
`Page.ready` protocol event. Otherwise, we deliver dialog events to the
unreported page.
We try to avoid closing firefox too early, fearing that this
might terminate clean shutdown sequence.
Usually we assume that `Browser.enable` is called before `Browser.close`
- however, this is not the case in certain tests. So we have to
ensure browser initialization in `Browser.close` as well.
In my local tests, this fixes the Firefox Pipe problem: it looks like
we were closing browser too quickly.
It looks like terminating browser when search service or addon manager is
not fully initialized results in a broken shutdown sequence. As of
today, this results in multiple errors in the browser STDERR. In future,
this might also result in browser stalling instead of terminating.
This starts awaiting search and addon manager termination.
References #3995
Using WebProgressListener events works in all cases. Currently
used `pageshow` event will stop being emitted in future when loading
was stopped with `window.stop()` api.
References #3995
This patch:
- moves `SimpleChannel` to synchronously dispatch buffered commands
instead of a `await Promise.resolve()` hack
- moves dialog & screencast handling from `PageHandler` to
`TargetManager`. This leaves `PageHandler` to be concerned solely about
protocol.
- removes `attach` and `detach` methods for worker channels: since
channels are buffering messages until the namespace registers, there's
no chance to loose any events.
- slightly simplifies `PageNetwork` class: it's lifetime is now
identical to the lifetime of the associated `PageTarget`, so a lot can
be simplified later on.
References #3995
In the current tip-of-tree Firefox, document channel is enabled by
default, so we have to enable it in order to roll further.
This patch:
1. Removes content disposition sniffing from content process since it
crashes renderer with document channel.
2. Merges all page-related handlers in a single `PageHandler` and
serializes network events wrt the `Page.frameAttached` event.
The serialization mentioned in (2) is necessary: frame attachment is
reported from the content process, and network events are reported from
the browsers process. This is an inherent race, that becomes exposed by
the document channel.
On a side note, (2) makes it possible to synchronously report all
buffered events in `SimpleChannel` (cc offline discussion with @dgozman
that highlighted an unsighty approach that we currently employ there: reporting
events in a subsequent microtask.)
References #3995
Max Schmitt
Andrey Lushnikov
Yury Semikhatsky
Joel Einbinder
Dmitry Gozman
Andrey Lushnikov
Pavel Feldman
Ross Wollman