Also reverted screenshot test changes from 4de14e7 as the breaking change was reverted upstream in Revert [251706@main] getComputedStyle(img).height returns string of a rounded int not a float WebKit/WebKit#1902
Fixes#8206.
Since #8206 is a long-awaited (~ 1 year old), popular (~ 45 reactions, frequently requested in community channels, etc.), this PR aims to unblock folks.
Notably, we do not innovate on the `webServer` API, despite knowing we're not in love with it. We'll save the innovation for either Plugins or a new `LaunchConfigs` option. (We haven't yet arrived at a Plugin API we like, and instead of launching a new option guessing what the "better" launchConfig API would be, let's wait and see how folks use this new Array-variant of `webServer` which—despite its name—can be used for non-Web Server launches!
When running without tty, line reporter outputs a line for each
percent of the tests, thus limiting the output to ~100 lines.
In addition, reporters now support PLAYWRIGHT_LIVE_TERMINAL
env variable to force tty mode.
* `clip` option is always passed from the client code
* with this change, we can no longer capture screenshot of a blinking
caret; the browser-side API doesn't have this capability.
Useful to set some options without coming up with an artificial name.
```js
test.describe(() => {
test.use({ colorScheme: 'dark' });
test('my test', () => {});
})
```
Currently, it is possible to run a function, e.g. a second `beforeEach` hook,
that will receive `null` for the fixture that has already failed before.
This PR skips running any user function that uses a fixture that has already
failed, just like if the fixture would be initialized again and failing for
the second time.
The following options now work across languages:
- `recordHar`
- `serviceWorkers`
In addition, object properties are now sorted alphabetically.
Drive-by: fixed `--target` help message to include all available targets.
Resolves#14255.
PNGs should be preferred as they are deterministic, but increasing this
limit should be fine for JPEG users. (Looking through jpeg-js source code, the actual memory allocation is based on the size of the image—so unless a user is hitting this limit already—this should not impact the memory consumption of Playwright.