Instead of checking lifecycle events on every change, we
notify precisely when lifecycle event in the subtree
is satisfied. This allows FrameTask to be later switched
to event-based approach, and will easily translate to the
rpc client.
We should not stall selector actions because of dialogs
and properly timeout instead. For this, we should not await
the handle.dispose() call because it will never happen
while dialog is shown.
Also, log information about dialogs to make it easier to debug.
We now query selector and take textContent synchronously. This
avoids any issues with async processing: node being recycled,
detached, etc.
More methods will follow with the same atomic pattern.
Drive-by: fixed selector engine names being sometimes case-sensitive
and sometimes not.
We currently have dispatchEventTask and waitForSelectorTask.
However, most selector-based operations make sense as tasks, to ensure
atomic execution, e.g. textContent(selector) or focus(selector).
This will fight hydration, elements recycling and other async issues.
In preparation, decouple tasks from selectors parsing so that
we can have common infrastructure for tasks.
- Gave all possible dom errors distinct names, and throw them on the node side.
- Separated errors into FatalDOMError and RetargetableDOMError.
Fatal errors are unrecoverable. Retargetable errors
could be resolved by requerying the selector.
- This exposed a number of unhandled 'notconnected' cases.
- Added helper functions to handle errors and ensure TypeScript catches
unhandled ones.
- unifies polling timeouts with everything else,
based on the client time instead of the server time;
- prepares polling tasks for cancellation token
behavior.
Unfortunately, RerunnableTask had to be rewritten almost
entirely.
These requests are usually internal ones, and we can safely abort them.
An example would be DevTools loading cached resources to show the content.
There will never be a matching Network.requestWillBeSent event, so we do not
report them to the user.
Since we are recommending Promise.all pattern anyway, this special
logic just adds to the possibility of timeout if something goes wrong.
For example, Firefox sometimes send Page.willOpenNewWindowAsynchronously
later than the new target arrives and input action just hangs.
