The dom lib inserts all dom related types into the project, which is often
undesirable when working on a NodeJS project.
This change injects global stubs for the dom types required by puppeteer, so
puppeteer can work without users having to add dom types to their project.
Closes#6989
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>
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.
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.
The existing behavior is expected to be unchanged as the value defaults to true.
Adding such option would allow user to skip the initial wait.
Issue: #3630
The `Page#click` method relies on `Mouse#click` for execution. `Mouse#click` triggers the `move`, `down`, and `up` methods in parallel waiting for all of them to finish, when they should be called sequentially instead.
Issue: #6462, #3347
Co-authored-by: Mathias Bynens <mathias@qiwi.be>
* feat(launcher): fix installation error on Apple M1 chips
The previous logic assumed that an arm64 arch is only available in Linux. WIth Apple's arm64 M1 Chip this assumption isn't true anymore.
Currently there are no official macOS arm64 chromium builds available, but we can make use of the excellent Rosetta feature in macOS which allows us to run x86 binaries on M1.
Once native macOS arm64 Chromium builds are available we should switch to those.
Issue: #6622
Co-authored-by: Mathias Bynens <mathias@qiwi.be>
