This changes the last actions, namely `click` and `press`, to not wait
for the ongoing navigations after the action.
Maintaining this behavior becomes tricky, because browsers move away from
guaranteed synchronous navigations to optimized performance. See #34377
for more details.
This is technically a breaking change. Most of the time, this should
not be noticeable, because the next action will auto-wait the navigation
and for any required conditions anyway. However, there are some patterns
revealed by our tests that are affected:
- Calling `goBack/goForward` immediately after an action. This pattern
requires `expect(page).toHaveURL()` or a similar check inbetween.
- Listening for network events during the action, and immediately
asserting after the action. This pattern requires `waitForRequest()`
or a similar promise-based waiter as recommended in best practices.
We maintain the opt-out `env.PLAYWRIGHT_WAIT_AFTER_CLICK` that reverts
to the old behavior for now.
Additionally, previous opt-out option `env.PLAYWRIGHT_SKIP_NAVIGATION_CHECK`
has been removed, because there have been just a single issue with it,
that was immediately addressed in a patch release.
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.
Currently, `loadstate` and `load` are two separate events in the protocol,
and are fired in this order. As a result, `waitForLoadState()` sometimes
resolves before the `'load'` event is fired, which is unexpected.
Also fixes a flaky test that assumed `load` event comes after `domcontentloaded`
for the empty page, which is not always a case in Chromium.
