This fixes:
```
D:\a\playwright\playwright\packages\playwright\lib\common\process.js:119
await processRunner.gracefullyClose().catch(() => {});
^
TypeError: Cannot read properties of undefined (reading 'gracefullyClose')
at gracefullyCloseAndExit (D:\a\playwright\playwright\packages\playwright\lib\common\process.js:119:23)
at process.<anonymous> (D:\a\playwright\playwright\packages\playwright\lib\common\process.js:81:11)
at process.emit (node:events:513:28)
at emit (node:internal/child_process:946:14)
at processTicksAndRejections (node:internal/process/task_queues:84:21)
```
from
[here](https://github.com/microsoft/playwright/actions/runs/6424299724/job/17444659548#step:7:2936).
`gracefullyCloseAndExit` gets called via `__stop__` and wants to use
`processRunner` var which gets created during `__init__`. So its
`undefined` when `__stop__` gets called.
Worker process start failure is reported as a test error and skips other
tests from the group.
If happened during stop (e.g. from a Ctrl+C) before worker has fully
initialized, this error is ignored.
Drive-by: send SIGINT in tests to the whole tree, to better emulate
Ctrl+C behavior.
A summary about the attempts we tried in
https://github.com/microsoft/playwright/pull/26931 for
https://github.com/microsoft/playwright/issues/26859 and
https://github.com/microsoft/playwright/issues/24591.
1. attempt: collect all the stdio from the worker host.
- this made it hard to capture the live console logs for the live trace
2. attempt: collect all the stdio from the worker host, but keep
proxying `process.{stdout,stderr}.write`.
- this solved the live console logs problem, since we could still listen
on them
- we found out about a race that the stdout/stderr streams can still
buffer data while the test already had finished
- we created a best effort flush implementation but didn't like the
complexity it introduced to the project
3. attempt: keep things like they are but also listen to stdio from the
worker host
- this solves the race of console.log in the test (things stay like they
are)
- this keeps live trace working (things stay like they are)
- a known pitfall is that it could result in logs which don't end up in
the reporter onStdOut/onStdErr, but it is already a significant
improvement over how it was before.
- before: they were not getting displayed
- after: they are getting displayed and there is a low likelihood that
they don't end up in the reporter API if the write happens slightly
before a test finished.
Closes#26931Fixes#26859Fixes#24591
- remove error details from the reports
- collapse flaky tests by default
- limit comment to 65365 character
GitHub API has comment length limit 65536 chars:
```
Unhandled error: HttpError: Validation Failed: {"resource":"IssueComment","code":"unprocessable","field":"data","message":"Body is too long (maximum is 65536 characters)"}
```
Additionally introduce `@playwright/browser-<browser>` packages that
just download the respective browser, but do not export anything.
References #26614.
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 patch:
- drops dependency on playwright-core in all our packages. Instead of
the dependency, packages are now built with `//packages/build_package.sh`
script.
- unifies `browsers.json` - now there's a single `//browsers.json` file
that is used to manage browser revisions.
This patch temporary switches canary publishing to `--dryn-run` from CI/CD so that we
can verify that it does sane things.
We'll unify all our package management scripts under `//packages/` in a
follow-up.
Fixes#2268
This patch removes the `PLAYWRIGHT_GLOBAL_INSTALL=1` variable
and instead introduces a new var - `PLAYWRIGHT_BROWSERS_PATH`.
You can specify `PLAYWRIGHT_BROWSERS_PATH` to affect where playwright
installs browsers and where it looks for browsers.
Fixes#1102
You can install playwright with
```
PLAYWRIGHT_GLOBAL_INSTALL=1 npm i playwright
```
to make it use a single shared location for all browser
downloads.
Fixes#1102
This generates typescript definitions based on the api.md, instead of autogenerating them from the typescript source code.
Now types
- only include the public api
- work with older versions of typescript
- include descriptions
- are more consistent
- are more complete
#6
This patch:
- removes `browserType.downloadBrowserIfNeeded()` method. The method
turned out to be ill-behaving and cannot not be used as we'd like to (see #1085)
- adds a `browserType.setExecutablePath` method to set a browser
exectuable.
With this patch, we take the following approach towards managing browser downloads:
- `playwright-core` doesn't download any browsers. In `playwright-core`, `playwright.chromium.executablePath()` returns `null` (same for firefox and webkit).
- clients of `playwright-core` (e.g. `playwright` and others) download browsers one way or another.
They can then configure `playwright` with executable paths and re-export the `playwright` object to their clients.
- `playwright`, `playwright-firefox`, `playwright-chromium` and `playwright-webkit` download
browsers. Once browsers are downloaded, their executable paths are saved to a `.downloaded-browsers.json` file. This file is read in `playwright/index.js` to configure browser executable paths and re-export the API.
- special case is `install-from-github.js` that also cleans up old browsers.
This patch starts respecting `PLAYWRIGHT_DOWNLOAD_HOST` env variable
in `playwright` package and it's vendored flavors (`playwright-firefox`,
`playwright-chromium` and `playwright-webkit`).
Fixes#1045
Playwright API is parametrized with a `downloadPath` - a path that
is used to download browsers and to look for downloaded browsers.
This patch starts respecting `downloadPath` as part of
`download-browser.js` utility.
This patch makes it so all our packages, like `playwright` and
browser-specific flavors, download browsers to their
directories rather then using directory of `playwright-core`.
This way yarn@1 caches are not busted: they didn't expect that directory
content might change after packages's explicit install step
is failed, there's that was what we were doing.
Fixes#1085
## playwright-chromium
- installs chromium
- exposes chromium api from playwright-core
## playwright-firefox
- installs firefox
- exposes firefox api from playwright-core
## playwright-webkit
- installs webkit
- exposes webkit api from playwright-core
## playwright-core
- downloads no browsers
- contains all of the js code
- designed for internal use
## playwright
- downloads all browsers
- exposes the entire api from playwright-core
## github
- downloads all browsers, generates protocol definitions, builds typescript
- exposes "playwright-core" api
