If there's no platform specified for the chromium build, we should
detect the host platform.
This will make it pleasant to verify Chromium rolls locally.
Assuming there's a `CR` env variable pointing to the local chromium,
rolling would look like this:
- bump a revision in `//browser_patches/chromium/BUILD_NUMBER`
- run `//browser_patches/chromium/build.sh`
- run tests with pulled chromium: `CRPATH=$CR npm run ctest`
This is an alternative approach to #3698 that was setting up a custom
mapping between chromium revisions and our mirrored builds. For example, we were
taking chromium `792639` and re-packaging it to our CDN as Chromium 1000.
One big downside of this opaque mapping was inability to quickly
understand which Chromium is mirrored to CDN.
To solve this, this patch starts treating browser revision as a fractional number,
with and integer part being a chromium revision, and fractional
part being our build number. For example, we can generate builds `792639`, `792639.1`,
`792639.2` etc, all of which will pick Chromium `792639` and re-package it to our CDN.
In the Playwright code itself, there are a handful of places that treat
browser revision as integer, exclusively to compare revision with some particular
revision numbers. This code would still work as-is, but I changed these places
to use `parseFloat` instead of `parseInt` for correctness.
Currently, we mirror Chromium revisions from gbuckets to our cdn and
name them same way as Chromium revision.
However, with the upcoming bundling of FFMPEG, we'd like to revision
Chromium packages separately, since our Chromium package will depend from
a number of factors:
- chromium upstream revision
- ffmpeg version
- extra files to add to the package or remove from the package
We should be able to produce a new Chromium build once any of these changes.
With this patch, to roll Chromium browser:
- update chromium revision number in the
`//browser_patches/chromium/UPSTREAM_CONFIG.sh`
- bump the build number in the `//browser_patches/chromium/BUILD_NUMBER`
Reference #3680
Firefox will sometimes send multiple requests with the same http channel id. When a frame is loaded, the favicon is requested in the parent frame, but with the same channel id. This can cause the document request to report the wrong frame, causing the test 'should capture iframe navigation request' to fail. It fails consistently on my computer.
This patch adds the content policy type into the http channelId to better distinguish requests. Maybe there is something better we can do? It looks like we use channelId has request ids, so there might be more bugs with these favicon requests in playwright?
* This changes the archive.sh script to use the webkit generate-bundle
tool to generate the MiniBrowser bundles instead of using our custom
logic.
* pw_run.sh is simplified because the new bundles include a wrapper
script that sets the needed LD_LIBRARY_PATH environment variables.
pw_run.sh now calls this wrapper script (for GTK or WPE) instead of
calling the MiniBrowser binary directly when running from a bundle.
Co-authored-by: Andrey Lushnikov <aslushnikov@gmail.com>
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`
Relates #3258
After a chat with @aslushnikov we add this in two iterations. The first one (this PR) is about scheduled runs for testing the latest tip-of-tree version of the browsers daily and the next PR is about opening an automated PRs once its passing (not sure if its worth to add for failing too) or sending Telegram/Slack notifications.
Current status is that Firefox (around 2 hours) and WebKit (around 3-4 hours) works.
Known issues which I fix before we merge:
- ~~Changes in `test/base.fixture.ts` will get extracted in #3453~~
Feel free to review, current blockers are before we can merge:
- ~~#3453~~
- potential git clone optimisation by aslushnikov
`MediaFeatureValuesChanged` is what their devtools code uses to update the styles. I tried using their code directly, but it doesn't play nicely with navigations so I decided to stick with ours.
