This pull request to adds better support for OOP iframes (see #2548)
The current problem with OOP iframes is that they are moved to a different target. Because of this, the previous versions of Puppeteer pretty much ignored them.
This change extends the FrameManager to already take OOP iframes into account and hides the fact that those frames are actually in different targets.
Further work needs to be done to also make the NetworkManager aware of these and to make sure that settings like emulations etc. are also properly passed down to the new targets.
Puppeteer already allows creating a new CDP session
via target.createCDPSession but there is no way
to get access to any existing session to send
some additional commands.
Until now, the click would be always sent to the middle
point of the target element. With this change, one can define
offsets relative to the border box of the elements and click
different areas of an element.
The current documentation for running with an Alpine-based Docker image
recommends using Chromium 89 / Puppeteer 6.0.0.
Chromium 92 is now supported by Puppeteer 10.0.0; this commit bumps the
recommended versions.
Prior to this patch, the example results in `browser.close()` being executed before the file is generated/written to disk. One needs to listen for the `end` event on the `ReadableStream` before closing the browser, otherwise an exception is raised:
UnhandledPromiseRejectionWarning: Error: Protocol error (IO.read): Target closed
This patch adds a reject callback to the _processClosing promise and executes it if it catches an error on removeFolderAsync(...).
Co-authored-by: Mathias Bynens <mathias@qiwi.be>
This change adds a new `channel` parameter to `puppeteer.launch`. When specified, Puppeteer will search for the locally installed release channel of Google Chrome and use it to launch. Available values are `chrome`, `chrome-beta`, `chrome-canary`, `chrome-dev`. This parameter is mutually exclusive with `executablePath`.
With this change,`request.respond`, `request.abort`, and `request.continue` can accept an optional `priority` to activate Cooperative Intercept Mode. In Cooperative Mode, all intercept handlers are guaranteed to run and all async handlers are awaited. The interception is resolved to the highest-priority resolution. See _Cooperative Intercept Mode and Legacy Intercept Mode_ in `docs/api.md` for details.
