* fix: ensure dom binding is not called after detatch
Fixes#7814
* refactor: detach listeners instead
* refactor: safer approach
* fix: test in test/page.spec.ts
Co-authored-by: Alex Rudenko <OrKoN@users.noreply.github.com>
When defining a chunk size for <CDPSession>.send('IO.read', { handle, size }), the CDPSession will occasionally indicate that it has reached the end of file without sending a full pdf. This is documented by the associated issue.
This behavior is not reproducible when leaving out the size parameter. Since the size parameter is not required on the CDPSession side and is merely a suggestion on the stream side, we can safely leave it out.
Issues: #7757
If an iframe has a border, it has to be added to the offsets
too. We can work around it by using the content box coordinates
for the offsets. That should also prevent discrepancies if the
iframe has a padding set.
The doc for boundingBox says that it should return the boundingBox
relative to the main frame, therefore, this fix would make the
actual implementation correspond to the documentation. boxModel
documentation does not have this note but I think it'd make sense
to have it match the behaviour of the boundingBox API.
So it appears that all bindings are added to the secondary world and all
evaluations are also running there. ElementHandle.evaluate is returning
handles from the main world though. Therefore, we need to be careful
and adopt handles to the right context before doing waitForSelector
So it appears that all bindings are added to the secondary world and all
evaluations are also running there. ElementHandle.evaluate is returning
handles from the main world though. Therefore, we need to be careful
and adopt handles to the right context before doing waitForSelector.
This updates the regular expression used to parse aria attribute
selectors so that single quotes may be used as an alternative to double
quotes, e.g. `aria/Single button[role='button']`.
Issues: #7721
Co-authored-by: Andy Earnshaw <andy.earnshaw@gmail.com>
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.
In some situations, Puppeteer is left in an invalid state because protocol errors that could have been handled by the user where just hidden from them. This patch removes some of these cases and also makes sure that unhandled promise rejections lead to a test failure in mocha.
Enable developers to handle 'Invalid header' errors instead of hiding them to make sure they can address them properly.
Co-authored-by: Jan Scheffler <janscheffler@chromium.org>
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.
Up to now, only strings starting with '//' are considered as to XPath selectors. Unfortunately, this is too restricting. This fix allows valid XPath selectors starting with: '/', './', and even '(//*[1])'
The values of these constant variables are always the exact same when the `parseAriaSelector()` function is called, so these can be moved out of the function.
* fix: added parts of website
* fix: removed unnecessary lines
* fix: updated contributing.md
* fix: added parts of sidebar
* fix: added all APIs
* fix: added version 10.0.0
Co-authored-by: Jack Franklin <jacktfranklin@chromium.org>
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.
This patch removes the redundant `await` from the block while fetching the target. The value in the map is a `Target` instance, which itself is not an async resource.
This commit adds drag-and-drop support, leveraging new additions to the CDP Input domain (Input.setInterceptDrags, Input.dispatchDragEvent, and Input.dragIntercepted).
* fix: modified comment for method product, platform and newPage
* fix: added comment for browsercontext, StartCSSCoverage, StartJSCoverage
* fix: corrected comments for JSONValue, asElement, evaluateHandle
* fix: corrected comments for JSONValue, asElement, evaluateHandle
* fix: added comments for some of the method
* fix: added proper comments
* fix: added comment for some methods in page.ts
* fix: rectified the comments
* fix: changed some of the comments
* fix: added comments for 3 more methods of class page
* fix: added comments for 3 more methods of class page
Co-authored-by: Jack Franklin <jacktfranklin@chromium.org>
* fix: modified comment for method product, platform and newPage
* fix: added comment for browsercontext, StartCSSCoverage, StartJSCoverage
* fix: corrected comments for JSONValue, asElement, evaluateHandle
* fix: corrected comments for JSONValue, asElement, evaluateHandle
* fix: added comments for some of the method
* fix: added proper comments
* fix: added comment for some methods in page.ts
* fix: rectified the comments
* fix: changed some of the comments
Co-authored-by: Jack Franklin <jacktfranklin@chromium.org>
* fix: modified comment for method product, platform and newPage
* fix: added comment for browsercontext, StartCSSCoverage, StartJSCoverage
* fix: corrected comments for JSONValue, asElement, evaluateHandle
* fix: corrected comments for JSONValue, asElement, evaluateHandle
* fix: added comments for some of the method
* fix: added proper comments
Co-authored-by: Jack Franklin <jacktfranklin@chromium.org>
This commit updates the JSHandle class to take a generic representing
the underlying object that it's wrapping. We can then define
`ElementHandle` as a class that extends `JSHandle<Element>` and begin
to get better type inference.
Prior to this commit the following code would have `d` set to `any`:
```
const div: page.$<HTMLDivElement>('div')
const text = await div.evaluate(d => d.innerText)
```
You could work around this in two ways:
```
const text = await div.evaluate<(d: HTMLDivElement) => string>(d => d.innerText)
const text = await div.evaluate((d: HTMLDivElement) => d.innerText)
```
But both of these have two issues:
1. Requires the user to type extra information.
2. There's no type checking: in the code above I could type `d` as
`number` and TS would be happy.
With the change here to `evaluate` the user can now type the original
code:
```
const div: page.$<HTMLDivElement>('div')
const text = await div.evaluate(d => d.innerText)
```
And TypeScript will know that `d` is an `HTMLDivElement`.
This change brings us inline with the approach that @types/puppeteer
takes. If we land this and it works, we can do the same with
`evaluateHandle` to hopefully make a similar improvement there.
BREAKING: because this changes the types, which were previously `any`,
this is technically a breaking change as users using TS could start
getting errors after this change is released.
This PR updates some code to remove constant ESLint warnings. It also
upgrades those warnings to errors - so that they have to be resolved
as part of the PR, rather than landing as a warning and causing noise.
Fixes#7229.
We're seeing odd failures with Prettier on some CI branches; my hunch is that they are installing different versions of the package and therefore getting formatting conflicts. This PR updates them all and pins them to specific versions - something we should probably consider generally, or remove our `package-lock.json` from the gitignore.
