The following actions keep `noWaitAfter` option:
- `click`
- `selectOption`
- `press`
All other actions that used to have `noWaitAfter` now
only 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 with never stalling instead.
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.
