This patch brings in antialiasing tests from `looks-same` project for
our experimental `ssim-cie94` comparator.
One of the new tests found a bug in our implementation.
References https://github.com/microsoft/playwright/issues/24312
Since
99ff08340f
search event is disabled in cocoa.
---------
Signed-off-by: Max Schmitt <max@schmitt.mx>
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Max Schmitt <max@schmitt.mx>
Migrate to version 4 which returns a promise rather than leverages a
callback. -> https://www.npmjs.com/package/rimraf?activeTab=readme
- contains its own types, eliminate "@types/rimraf"
- Parameter `maxBusyTries` changed to `maxRetries`
https://github.com/microsoft/playwright/issues/23907
This fixes the following scenario. You press Command + C during the
test-execution, then a global teardown will execute, which takes a long
time and before this on macOS did sometimes end up in an unwanted SIGINT
received inside the globalTeardown handler. After this change this won't
happen anymore.
We store shard number in the report metadata event and then sort shard
files by shard number. This guarantees that within each project sharded
events will always go in stable order.
Usually, we can just chain two locators with `>>` to implement
`Locator.locator(locator)`. However, this does not play nicely with more
advanced inner locators like `or` and `and`:
```ts
const child = page.locator('input').or(page.locator('button'));
page.locator('parent').locator(child);
```
One would expect the above to locate "input or button" inside a
"parent". However, currently it locates "input inside a parent" or
"button", because it's translated to `parent >> input >>
internal:or="button"`.
To fix this, we have to wrap inner locator into `internal:chain` and
query it separately from the parent.
Fixes#23724.
We have been optionally adding `-<number>` in multiple places, and these
might collide in various circumstances, for example: two contexts at the
same time, one of them has the second trace chunk.
References #23387.
Partial fix for https://github.com/microsoft/playwright/issues/6319
After this fix, the following scenario won't leak and the context state
(cookies, storage, etc) can be reused by the new page sessions:
```js
for (let i = 0; i < 1000; ++i) {
const page = await context.newPage();
await page.goto('...');
await page.close('...');
}
```
Fixes#24144.
Previously, we only matched by url, which confuses GET and HEAD requests
where the latter is usually zero-sized.
Also make sure that resources are sorted by their monotonicTime, since
that's not always the case in the trace file, where they are sorted by
the "response body retrieved" time.
