This patch moves FFMPEG building to buildbots:
- `ffmpeg-mac.zip` is built on Mac 10.14 machine
- `ffmpeg-win32.zip` and `ffmpeg-win64.zip` are cross-compiled on
Ubuntu 20.04 machine
All builds across the platforms share the same config:
- the same versions of `ffmpeg` and `libvpx`
- the same build configuration for both `ffmpeg` and `libvpx`
The config could be found in the `//browser_patches/ffmpeg/CONFIG.sh`.
The builds will be then copied manually and committed to the git
repository.
This patch:
- moves ffmpeg binaries from `//bin/` to `//third_party/ffmpeg`
- adds [COPYING.GPLv3](https://github.com/FFmpeg/FFmpeg/blob/master/COPYING.GPLv3)
ffmpeg license
- changes npm packaging to include `//third_party/ffmpeg` only in `playwright` and `playwrihgt-chromium` a
browser(firefox): fix automatic http->https redirect
Sometimes, Firefox does an automatic http->https redirect without hitting
the network (e.g. for http://wikipedia.org). In this case, the http request
is very strange:
- it does not actually hit the network;
- it is never intercepted;
- we cannot access its response because there was no actual response.
So, we had a bug where:
- redirects inherited the original request's listener;
- that listener was throwing an error.
This lead to the error in the listeners onDataAvailable call chain,
and original listener that renders the response was never called,
resulting in an empty page.
This change:
- ignores the original request that did not hit the network;
- does not inherit the listener;
- adds try/catch around problematic calls.
This patch:
- adds FFMPEG binaries to the NPM packages
- adds a screencast test to make sure that screencast works. This currently relies on private screencast APIs.
NOTE: with this patch playwright package size grows from `650KB` to `4.2MB`.
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.
This patch:
- stop relying on stdout from `//packages/build_package.js` to get
output paths. This was a legacy code that's not needed anymore
- remove stray output from `//packages/build_package.js`
We used to do fetch() to decode the file buffer. However, this is
blocked by strict CSP policy. Instead, we can use explicit
string -> bytes conversion, and trade performance for CSP compliance.
We currently launch and then close the empty browser. This does not
trigger many codepaths related to web page process creation and
browser context.
With opening and navigating a page, we do a more real-life test.
This exposes an issue from #3740.
