This makes it much nicer to use `BrowserType` because it no longer has a template.
Technically a breaking change because of the rare edge case where someone used their own non-browser type inside the template, but I don't consider that intended behavior and think this is fine.
Browser registry is responsible for 3 things:
1. Remove downloaded browsers if there are no packages that refer to them
2. Install default browsers needed for the current package
3. Install browsers on-demand when used through Playwright CLI
Currently, registry relies on a single "download" field in `browsers.json`
to carry both (1) and (2). However, browsers in (3) are marked as
`download: false` so that they aren't installed automatically in (2), so
auto-remove procedure in (1) removes them on subsequent installation.
One possible approach to fix this would be modifying package's `browsers.json` to
change `download: false` to `true` when browsers are installed with
Playwright CLI. This approach was explored here:
bc04a51800
We decided against this since we have a history of issues related to
package modifications after NPM installation. This breaks all
sorts of yarn/npm caching mechanisms.
Instead, this patch is a two-step refactor:
- remove the "download" field in `browsers.json`. Now, all registries
(including old ones from previously-released versions) will retain any
browsers that are mentioned in the `browsers.json`.
- add a new flag "installByDefault", that is **only used** for default
installation.
With this change, the registry tasks are done like this:
- (1) auto-removal: if browser has a back reference, it is retained,
otherwise it is removed from registry
- (2) default installation: use only `installByDefault` to carry default installations
- (3) CLI installation: simply installs browsers. Since we retain
everythings that's referenced in (1), browsers aren't removed.
Fixes#5902
We get relative registry path when PLAYWRIGHT_BROWSERS_PATH or HOME is relative.
In this case, it would be good to resolve to the same absolute path
during installation and execution, and we can usually do that using INIT_CWD.
- Introduce internal "out of process" start()/stop() mode.
- This mode is used both in regular tests and installation tests.
- Emulate basic driver installation, browser download and running.
This patch starts downloading FFMPEG like we download our browsers
instead of bundling it in the NPM package.
With this patch, NPM size is reduced from 8.8MB to 1.7MB.
Consequences:
- `npx playwright` is drastically faster now
- playwright driver for language bindings is way smaller
- projects that bundle Playwright can pass Apple Notorization
Fixes#5193
- Allow specifying which browsers to install. This comes handy in playwright-cli.
- Print "npx playwright" as a tool name in help messages, instead of "cli".
Currently, `playwright-core` installation would check browser registry
and remove any unused browsers. This, however, might be unexpected
since `playwright-core` shouldn't touch browser registry at all.
Fixes#4083
- This leaves just `recordVideos` and `videoSize` options on the context.
- Videos are saved to `artifactsPath`. We also save their ids to trace.
- `context.close()` waits for the processed videos.
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 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`.
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`
The reason for this change is that in Playwright Python we would need the related `protocol.yml` and `api.md` for the installed NPM package. For that we could either add the Git hash to the released package e.g. as a file (and go over the GitHub repo to get the file content) but Pavel proposed that it might be better to include the two files in the NPM package.
Tested locally by adding to the `utils/publish_all_packages.sh` script `--dry` to the NPM publish commands.
cc @aslushnikov @pavelfeldman
Related issues: https://github.com/microsoft/playwright-python/pull/101 and https://github.com/microsoft/playwright-python/pull/96
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.
