Also considered an alternative to not perform the locator handler check
during one-shot, but that would be somewhat against the promise of the
locator handler that is supposed to run **before** every expect check.
Fixes#32089.
The following actions keep `noWaitAfter` option: `click`, `selectOption`
and `press`.
All other actions that used to have `noWaitAfter` now behave like it was
set to true, not waiting for follow-up navigations. In the docs, this
option is marked as completely ignored.
A small logic change was made to compensate for this behavior: when
waiting for the `hitTargetInterceptor`, we now race it against
navigations to avoid stalling when navigation stalls. Previously,
waiting for the interceptor was disabled when `noWaitAfter` was passed,
and since it's impossible to pass this option now, we mitigate by never
stalling instead.
Fixes#31469.
- Automatically waiting for the overlay locator to be hidden, with
`allowStayingVisible` opt-out.
- `times: 1` option.
- `removeLocatorHandler(locator, handler)` method.
- Passing `locator` as first argument to `handler`.
Fixes#30471. Fixes#30424. Fixes#29779.
This helps in a case where navigating to an origin fails for some
reason, for example because a registered service worker loads some
content into the supposedly blank page.
Fixes#29402.
The metadata.error change was brought back in
https://github.com/microsoft/playwright/pull/29271and it broke java port
as we could have error and result set simulteniously. This PR moves the
logic to the trace recorder instead and keeps the protocol contract
clear that either error or result is present, but not both.
This is a follow-up to 119afdf788 Since
continue/fulfill/abort now may throw on the server after page has been
closed, we need to catch the errors manually. On the client it's fixed
by the original change.
This fixes errors in the existing tests:
```
1) [chromium] › library/browsercontext-route.spec.ts:172:3 › should support Set-Cookie header ────
Error:
at ../packages/playwright-core/src/server/chromium/crConnection.ts:147
145 | const id = this._connection._rawSend(this._sessionId, method, params);
146 | return new Promise((resolve, reject) => {
> 147 | this._callbacks.set(id, { resolve, reject, error: new ProtocolError('error', method) });
| ^
148 | });
149 | }
150 |
at /Users/yurys/playwright/packages/playwright-core/src/server/chromium/crConnection.ts:147:57
at new Promise (<anonymous>)
at CRSession.send (/Users/yurys/playwright/packages/playwright-core/src/server/chromium/crConnection.ts:146:12)
at RouteImpl.continue (/Users/yurys/playwright/packages/playwright-core/src/server/chromium/crNetworkManager.ts:566:25)
at FrameManager.requestStarted (/Users/yurys/playwright/packages/playwright-core/src/server/frames.ts:299:23)
at CRNetworkManager._onRequest (/Users/yurys/playwright/packages/playwright-core/src/server/chromium/crNetworkManager.ts:314:57)
at CRNetworkManager._onRequestPaused (/Users/yurys/playwright/packages/playwright-core/src/server/chromium/crNetworkManager.ts:202:12)
at CRSession.emit (node:events:517:28)
at /Users/yurys/playwright/packages/playwright-core/src/server/chromium/crConnection.ts:172:14
at runNextTicks (node:internal/process/task_queues:60:5)
at processImmediate (node:internal/timers:447:9)
```
Reference https://github.com/microsoft/playwright/issues/28490
Instead of having `didClose` based on page creation/destruction and
`didDisconnect` based on session lifetime, we make session lifetime
being managed by the `CRPage`/`FFPage`/`WKPage` instead.
In firefox, the `frameRequestedNavigation` is coming from renderer and
thus can happen **after** the `Network.requestWillBeSent`, which is
dispatched from the browser process.
Fixes https://github.com/microsoft/playwright/issues/24132
The call was added back in 2019 to stop network loading. See commit:
56a48559c2
However, there's no evidence that this call is needed any more:
- all the tests pass without it
- `window.stop()` behavior is poorly defined, so relying on it is
unfortunate.
The `window.stop()` call, however, causes trouble while rolling firefox:
under certain condititions, the call prevents document from firing the
`load` event in the `document.open().write(..).close()` sequence that
comes immediately after the call. While this does look like a bug in
Firefox itself, we failed to reproduce it in isolation.
For the reference, the following tests fail with the Firefox 116 (using
`PWTEST_TRACE=1` triggers the race condition somewhere):
```bash
PWTEST_TRACE=1 npm run ftest cli-codegen
```
- properly annotate continued requests
- nest `attach` steps inside the related `expect` step
- fix primary-id-to-non-primary-id mapping
- make sure images in trace are not draggable
Fixes#23693
---------
Signed-off-by: Andrey Lushnikov <aslushnikov@gmail.com>
Co-authored-by: Max Schmitt <max@schmitt.mx>
I added a new option to the screenshot method to customize the color of
the box when we want to mask some elements for the screenshot.
The default color is pink `#FF00FF`, but with this new option you can
specify the color you like the most, like a nice green `#00FF00`:
```js
await page.screenshot({
mask: [page.locator('div').nth(5)],
maskColor: "#00FF00",
})
```
---------
Signed-off-by: Jasiel Guillén <darkensses@gmail.com>
The method accepts a `ratio` option to assert the ratio
of the element in viewport. `ratio` defaults to `Number.MIN_VALUE`.
NOTE: this reverts commit d950f5b6ee and
adds `ratio` option support + does the rename.
Fixes#8740
