Pre-BigSur, MacOS updates were labeled as "minor" releases, so we had
to bake separate builds for different 10.X releases.
In BigSur era, it doesn't seem to be the case, so for now we can re-use
our BigSur builds across all BigSur versions (11.0, 11.1 and 11.2).
If we ever need to have a custom build for some bigsur minor version,
e.g. `11.6`, we'll have a new browser platform along with generic
`mac11` platform.
Fixes#4775.
11.1 is an official update for macOS Big Sur. We should maybe add a custom macOS version parser which falls back if minor version changes so we don't have to maintain all the versions manually.
Fixes#4722
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.
- Never write to console on the server side - we use stdout for
communication. This includes logPolitely and deprecate.
- Pass undefined instead of null in some BrowserContext methods.
- Use explicit _setFileChooserIntercepted instead of on/off magic.
This starts downloading newer Chromium archives from our CDN, but
retains old endpoint for older Chromium revisions.
This backwards compatibility might help later on to implement
a browser bisecting tool.
References #3259
This makes it easier to reason about our packages.
The only difference is what each package downloads.
When the browser is not downloaded, it will fail to launch.
Each browser gets a 'download' attribute in the browser.json file.
This establishes a single naming for all our blobs with browser
builds that we upload to CDN: `<browser-name>-<os-version>`
- `<browser-name>` is either `firefox` or `webkit`.
- `os-version` is the OS that was used to produce the build.
References #2745
This patch:
- specializes "linux" scripts into "Ubuntu 18.04" scripts
- renames all future linux blobs on CDN:
* `firefox-linux.zip => firefox-ubuntu-18.04.zip`
* `minibrowser-gtk.zip => minibrowser-gtk-ubuntu-18.04.zip`
* `minibrowser-wpe.zip => minibrowser-wpe-ubuntu-18.04.zip`
* `minibrowser-gtk-wpe.zip => minibrowser-gtk-wpe-ubuntu-18.04.zip`
- updates downloader to deal with the new names
References #2745
In addition to `PLAYWRIGHT_DOWNLOAD_HOST` env variable, this patch adds a per-browser
configuration:
- `PLAYWRIGHT_CHROMIUM_DOWNLOAD_HOST`
- `PLAYWRIGHT_FIREFOX_DOWNLOAD_HOST`
- `PLAYWRIGHT_WEBKIT_DOWNLOAD_HOST`
This reverts 2 commits:
- "fix(installer): create tmp directory inside `browserPath` (#2498)"
commit 946b4efa3b55dd96396b1c34f1f159735beaaaea.
- "feat: support atomic installation of browsers (#2489)"
commit 3de0c087bcc2592ae9fa65a79a29129e2b153e06.
This addresses installation issues we see in some CI environments.
Currently, Ctrl-C while extracting browser might yield users in
a bad place.
This patch extracts browsers in a temp directory that is later
moved to a installer registry.
