Previously, we closed pages one by one before closing the browser when
shutting down the persistent context. This logic was introduced in
https://github.com/microsoft/playwright/pull/4040 to properly finish
video recordings in persistent context.
Such a process makes it unnecessary brittle to close the persistent
context. For example, Chromium headless is sometimes unable to close the
last persistent page for unknown reasons.
Instead, we can just stop video recordings manually and close the
browser right away.
Fixes#18229.
Instead of requiring all frames in the subtree to receive a particular
event, we rely on the browser's definition of load and DOMContentLoaded.
This changes logic in a few edge cases:
- Some browsers do not emit load event upon window.stop() at all.
- DOMContentLoaded does not wait for subframes, so they might not be
ready when passing `{ waitUntil: 'domcontentloaded' }`.
`networkidle` preserves the old logic.
Fixes#15474.
Notes:
* page-level requests that are also handled by a SW's fetch handler, should not be interceptable at the page-level
* `Network.requestWillBeSent` does not provide enough metadata for Playwright to fire the `request` event at that time, so it does it as soon as it gets to the end of the request lifecycle
Potential fixes to avoid startup races:
- Wait for "juggler listening" message.
- Make sure `transport.onclose` is called when connecting to the transport after the actual pipe closure.
- Do not resolve raw headers upon `loadingFinished`, since they may still come later in
`responseReceivedExtraInfo`.
- Introduce separate promises for `encodedBodySize`, `transferSize` and `responseHeadersSize`.
- Make sure we resolve each of them either with data available
from the browser, or a fallback calculation.
- Set raw response headers for redirects on WebKit.
- Do not stall on cached responses in Chromium, they have erroneously set `hasExtraInfo` flag.
- Use `transferSize` that is available in Firefox protocol.
fix(network): make allHeaders wait until all header are available
Before, calling `allHeaders()` from `page.on('request')` would yield
provisional headers instead.
With these changes:
- In Firefox, all headers are available immediately.
- In Chromium, all headers are available upon requestWillBeSentExtraInfo.
- In WebKit, all headers are available upon responseReceived.
- In all browsers, intercepted requests use "provisional" headers
as all headers, since there is no network stack to change the headers.
Drive-by: migrated Chromium to `hasExtraInfo` flags that simplifies
the logic quite a bit.
fix(chromium): work around about:blank issue on Chromium
We don't receive the `loaderId` which translates to `newDocumentId`,
so we expect the same-document navigation. Instead, we can wait
for any new-document navigation as a workaround, only for `about:blank`.
This also reverts commit f0f65fa247ac9cb594acd45b52dc851e60109172.
