- fix#6340
- Exposes all the network related events (request, response, requestfailed, requestfinished) through the browser context to allow for managing network activity even if the is any navigations through popups or to new tabs which could result in creation of multiple page objects.
These methods are safe to call while the page is still open, or when it is
already closed. Works in remotely connected browser as well.
Also makes video.path() to throw for remotely connected browser.
Under the hood migrated Download and Video to use the common Artifact object.
Consider the following situation (one among many possible).
- FrameA has an oopif child FrameB;
- FrameA navigates to same-process origin (e.g. about:blank);
- at the same time, FrameC is attached to the FrameB in the
FrameB's process.
In this case, we get `frameNavigated` event for FrameA, immediately
followed by `frameAttached` event for FrameC. Since we detach all
FrameA's child frames on navigation, including the oopif FrameB,
there is no parent frame for FrameC to attach to.
In general, multiple processes coming from oopif may send their
events in wildly different order, and their view about the frame
tree may not always correspond to the "up to date" frame tree as
seen from the main frame's process. We try to keep our frame tree
aligned with what main process thinks, and ignore events that
reference frames absent in this tree.
Drive-by: handle filechooser exceptions because of async processing.
When `page.reload()` is racing against the renderer-initiated
navigation, we might end up with `waitForNavigation()` being rejected
before the reload implementation is able to catch it.
To avoid that, carefully use Promise.all and await `waitForNavigation`
from the get go.
Same happens to `page.goForward()` and `page.goBack()`.
Currently, we always throw from FrameSession._stopScreencast
when not running with video, and immediately catch it in
CRPage.didClose (thanks to debugger to point that).
Overall, we have code prepared for start/stop API, which
we never did, so it makes sense to simplify code a bit,
and throw if something goes wrong.
