When not specified, launch timeout is 3 minutes, taken from the
`DEFAULT_LAUNCH_TIMEOUT` constant.
Also, use the default launch timeout for `electron.launch()` instead of
default regular timeout.
A separate process is `spawnSync`'ed on process exit to cleanup
temporary directories, introduced in #13769 that followed up after
#13343.
A separate process might stall for various fs-related issues, which
prevents the original process from exiting.
With the recent changes, we always gracefully close and cleanup after
all launched executables before calling `process.exit()`, and so it
should only be possible to leave temp directories when using Playwright
and calling `process.exit()` programmatically without closing browsers.
We can now drop the extra process and rely on `rimraf.sync` for
last-resort cleanup in these rare circumstances.
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
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`
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.
This will keep UI Mode running in browser mode. When launched in normal
persistent context mode, we know when the persistent context closes, so
we can run the project teardown code.
Fixes https://github.com/microsoft/playwright/issues/23801
So, the following will work:
```
page.frameLocator('iframe').locator('span').or(page.frameLoactor('iframe').locator('div'))
```
The following will not work, because frame locators are not exactly the
same:
```
page.frameLocator('#iframe1').locator('span').or(page.frameLoactor('#iframe2').locator('div'))
```
Also improve the error message to be more readable and include the
locator.
Fixes#23697.
Closes https://github.com/microsoft/playwright/issues/23566
n.b., while that issue describes a fairly specific "use case", this
logging is simple and generic. It seems very plausible that it can help
diagnose all sorts of issues.
Cheers - V
