This reverts commit 0aa2f06f68959e2515f62ea9bb570cf1815230b2.
Discussed the new permission in the API review and decided not to
proceed with the feature as we are not ready to commit to supporting it
yet:
* the API is Chromium specific
* the API is still experimental
* there is no clarity to what extend the screen manipulation APIs will
work in old headless which is our main test environment
We'll keep an eye on the demand for the feature and may get back to
implementing it in the future.
Reference: https://github.com/microsoft/playwright/issues/27198
Redirects are always autoresumed, so the will always receive extra info
with raw headers. We only want to make raw headers available immediately
when there is a route.
Reference https://github.com/microsoft/playwright/issues/31351
When websocket disconnects during `browserType.connect()` call, the
error looks like this now:
```
browserType.connect: Custom error message received over WebSocket
```
Previously, it was a generic error:
```
browserType.connect: Target page, context or browser has been closed
```
Workers use page's session for `Fetch` domain and worker's session for
`Network` domain. Therefore, `CRNetworkManager` should keep track of the
right session for each domain separately.
This is covered by currently flaky tests:
- `should report and intercept network from nested worker`,
- `should intercept network activity from worker`,
- `should intercept network activity from worker 2`.
This covers blocked requests, e.g. mixed-content, that receive
`loadingFailed` with empty `errorText`.
Also, forcefully resolve `allHeaders()` in this case, since we know
there will be no actual network headers.
Fixes#29833.
It was already handling worker sessions, but not OOPIFs. As a result,
some functionality was properly implemented only for OOPIFs and not for
workers.
This change removes OOPIFs fanout for network-related calls from CRPage
and moves that to the CRNetworkManager, now also covering workers.
We stopped catching all exceptions in
https://github.com/microsoft/playwright/pull/28539 in hope that we'll
get loadingFailed even before Fetch.continue/fulfill command's error.
Turns out this is racy and may fail if the test cancels the request
while we are continuing it. The following test could in theory reproduce
it if stars align and the timing is good:
```js
it('page.continue on canceled request', async ({ page }) => {
let resolveRoute;
const routePromise = new Promise<Route>(f => resolveRoute = f);
await page.route('http://test.com/x', resolveRoute);
const evalPromise = page.evaluate(async () => {
const abortController = new AbortController();
(window as any).abortController = abortController;
return fetch('http://test.com/x', { signal: abortController.signal }).catch(e => 'cancelled');
});
const route = await routePromise;
void page.evaluate(() => (window as any).abortController.abort());
await new Promise(f => setTimeout(f, 10));
await route.continue();
const req = await evalPromise;
expect(req).toBe('cancelled');
});
```
Fixes https://github.com/microsoft/playwright/issues/29123
