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
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.
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.
As discussed offline, our testing scenarios assume running trusted
web content - so this warning is just a noise for this usecases.
When it comes to dealing with untrusted web content though, automation
authors need to make sure to not launch browsers under root in the first
place.
This is a large rework of selectors:
- Each BrowserContext now has a separate Selectors instance that has its own registrations.
Most of them share a single sharedSelectors instance, but contexts created for a connected
browser have their own instance.
- Connected browser now gets a RemoteBrowser object that encapsulates Selectors and Browser.
This Selectors object is registered with the api selectors.
- Public selectors.register api iterates over all registered Selectors channels
and registers in each of them.
- createSelector testing method migrated to ElementHandle._createSelectorForTest.
Sometimes I see "cannot call emit on the undefined" error on the bots.
This change adds some more logging, so we could potentially identify where
the issue comes from.
This introduces basic tracing enabled in our tests.
What is captured:
- network resources;
- snapshots at the start of most actions;
- snapshot after the test failure.
How this integrates with test runner:
- context fixture calls private method context._initSnapshotter() and uses Tracer to trace all events;
- all tests share a single test-results/trace-storage directory to store blobs;
- each test has its own trace file.
- npm run show-trace opens a bare-minimum trace viewer that renders snapshots.
Root index.js is only used for local development, so
assuming dev mode there is fine. This way we do not have
to worry about calling setUnderTest early enough.
