puppeteer/docs/faq.md

242 lines
10 KiB
Markdown
Raw Normal View History

2022-07-01 11:52:39 +00:00
# FAQ
## Q: Who maintains Puppeteer?
The Chrome DevTools team maintains the library, but we'd love your help and
expertise on the project! See our
[contributing guide](https://pptr.dev/contributing).
2022-07-01 11:52:39 +00:00
## Q: What is the status of cross-browser support?
Official Firefox support is currently experimental. The ongoing collaboration
with Mozilla aims to support common end-to-end testing use cases, for which
developers expect cross-browser coverage. The Puppeteer team needs input from
users to stabilize Firefox support and to bring missing APIs to our attention.
From Puppeteer v2.1.0 onwards you can specify
[`puppeteer.launch({product: 'firefox'})`](./api/puppeteer.puppeteernode.launch)
to run your Puppeteer scripts in Firefox Nightly, without any additional custom
patches. While
[an older experiment](https://www.npmjs.com/package/puppeteer-firefox) required
a patched version of Firefox,
[the current approach](https://wiki.mozilla.org/Remote) works with “stock”
Firefox.
We will continue to collaborate with other browser vendors to bring Puppeteer
support to browsers such as Safari. This effort includes exploration of a
standard for executing cross-browser commands (instead of relying on the
non-standard DevTools Protocol used by Chrome).
2022-07-01 11:52:39 +00:00
## Q: What are Puppeteers goals and principles?
The goals of the project are:
- Provide a slim, canonical library that highlights the capabilities of the
[DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/).
- Provide a reference implementation for similar testing libraries. Eventually,
these other frameworks could adopt Puppeteer as their foundational layer.
2022-07-01 11:52:39 +00:00
- Grow the adoption of headless/automated browser testing.
- Help dogfood new DevTools Protocol features...and catch bugs!
- Learn more about the pain points of automated browser testing and help fill
those gaps.
2022-07-01 11:52:39 +00:00
We adapt
[Chromium principles](https://www.chromium.org/developers/core-principles) to
help us drive product decisions:
2022-07-01 11:52:39 +00:00
- **Speed**: Puppeteer has almost zero performance overhead over an automated
page.
- **Security**: Puppeteer operates off-process with respect to Chromium, making
it safe to automate potentially malicious pages.
2022-07-01 11:52:39 +00:00
- **Stability**: Puppeteer should not be flaky and should not leak memory.
- **Simplicity**: Puppeteer provides a high-level API thats easy to use,
understand, and debug.
2022-07-01 11:52:39 +00:00
## Q: Is Puppeteer replacing Selenium/WebDriver?
**No**. Both projects are valuable for very different reasons:
- Selenium/WebDriver focuses on cross-browser automation; its value proposition
is a single standard API that works across all major browsers.
- Puppeteer focuses on Chromium; its value proposition is richer functionality
and higher reliability.
That said, you **can** use Puppeteer to run tests against Chromium, e.g. using
the community-driven
[jest-puppeteer](https://github.com/smooth-code/jest-puppeteer). While this
probably shouldnt be your only testing solution, it does have a few good points
compared to WebDriver:
- Puppeteer requires zero setup and comes bundled with the Chromium version it
works best with, making it
[very easy to start with](https://github.com/puppeteer/puppeteer/#getting-started).
At the end of the day, its better to have a few tests running chromium-only,
than no tests at all.
- Puppeteer has event-driven architecture, which removes a lot of potential
flakiness. Theres no need for evil “sleep(1000)” calls in puppeteer scripts.
- Puppeteer runs headless by default, which makes it fast to run. Puppeteer
v1.5.0 also exposes browser contexts, making it possible to efficiently
parallelize test execution.
- Puppeteer shines when it comes to debugging: flip the “headless” bit to false,
add “slowMo”, and youll see what the browser is doing. You can even open
Chrome DevTools to inspect the test environment.
2022-07-01 11:52:39 +00:00
## Q: Why doesnt Puppeteer v.XXX work with Chromium v.YYY?
We see Puppeteer as an **indivisible entity** with Chromium. Each version of
Puppeteer bundles a specific version of Chromium **the only** version it is
guaranteed to work with.
2022-07-01 11:52:39 +00:00
This is not an artificial constraint: A lot of work on Puppeteer is actually
taking place in the Chromium repository. Heres a typical story:
2022-07-01 11:52:39 +00:00
- A Puppeteer bug is reported:
https://github.com/puppeteer/puppeteer/issues/2709
- It turned out this is an issue with the DevTools protocol, so were fixing it
in Chromium: https://chromium-review.googlesource.com/c/chromium/src/+/1102154
- Once the upstream fix is landed, we roll updated Chromium into Puppeteer:
https://github.com/puppeteer/puppeteer/pull/2769
2022-07-01 11:52:39 +00:00
However, oftentimes it is desirable to use Puppeteer with the official Google
Chrome rather than Chromium. For this to work, you should install a
`puppeteer-core` version that corresponds to the Chrome version.
2022-07-01 11:52:39 +00:00
For example, in order to drive Chrome 71 with puppeteer-core, use `chrome-71`
npm tag:
2022-07-01 11:52:39 +00:00
```bash
npm install puppeteer-core@chrome-71
```
## Q: Which Chromium version does Puppeteer use?
Find the version using one of the following ways:
- Look for the `chromium` entry in
[revisions.ts](https://github.com/puppeteer/puppeteer/blob/main/packages/puppeteer-core/src/revisions.ts).
To find the corresponding Chromium commit and version number, search for the
revision prefixed by an `r` in [OmahaProxy](https://omahaproxy.appspot.com/)'s
"Find Releases" section.
- Look for the `versionsPerRelease` map in
[versions.js](https://github.com/puppeteer/puppeteer/blob/main/versions.js)
which contains mapping between Chromium and the smallest Puppeteer version
that supports it.
2022-07-01 11:52:39 +00:00
## Q: Which Firefox version does Puppeteer use?
Since Firefox support is experimental, Puppeteer downloads the latest
[Firefox Nightly](https://wiki.mozilla.org/Nightly) when the `PUPPETEER_PRODUCT`
environment variable is set to `firefox`. That's also why the value of `firefox`
in
[revisions.ts](https://github.com/puppeteer/puppeteer/blob/main/packages/puppeteer-core/src/revisions.ts)
is `latest` -- Puppeteer isn't tied to a particular Firefox version.
2022-07-01 11:52:39 +00:00
To fetch Firefox Nightly as part of Puppeteer installation:
```bash
PUPPETEER_PRODUCT=firefox npm i puppeteer
# or "yarn add puppeteer"
```
#### Q: Whats considered a “Navigation”?
From Puppeteers standpoint, **“navigation” is anything that changes a pages
URL**. Aside from regular navigation where the browser hits the network to fetch
a new document from the web server, this includes
[anchor navigations](https://www.w3.org/TR/html5/single-page.html#scroll-to-fragid)
and [History API](https://developer.mozilla.org/en-US/docs/Web/API/History_API)
usage.
2022-07-01 11:52:39 +00:00
With this definition of “navigation,” **Puppeteer works seamlessly with
single-page applications.**
2022-07-01 11:52:39 +00:00
#### Q: Whats the difference between a “trusted" and "untrusted" input event?
In browsers, input events could be divided into two big groups: trusted vs.
untrusted.
2022-07-01 11:52:39 +00:00
- **Trusted events**: events generated by users interacting with the page, e.g.
using a mouse or keyboard.
- **Untrusted event**: events generated by Web APIs, e.g. `document.createEvent`
or `element.click()` methods.
2022-07-01 11:52:39 +00:00
Websites can distinguish between these two groups:
- using an
[`Event.isTrusted`](https://developer.mozilla.org/en-US/docs/Web/API/Event/isTrusted)
event flag
- sniffing for accompanying events. For example, every trusted `'click'` event
is preceded by `'mousedown'` and `'mouseup'` events.
2022-07-01 11:52:39 +00:00
For automation purposes its important to generate trusted events. **All input
events generated with Puppeteer are trusted and fire proper accompanying
events.** If, for some reason, one needs an untrusted event, its always
possible to hop into a page context with `page.evaluate` and generate a fake
event:
2022-07-01 11:52:39 +00:00
```ts
await page.evaluate(() => {
document.querySelector('button[type=submit]').click();
});
```
#### Q: What features does Puppeteer not support?
You may find that Puppeteer does not behave as expected when controlling pages
that incorporate audio and video. (For example,
[video playback/screenshots is likely to fail](https://github.com/puppeteer/puppeteer/issues/291).)
There are two reasons for this:
- Puppeteer is bundled with Chromium — not Chrome — and so by default, it
inherits all of
[Chromium's media-related limitations](https://www.chromium.org/audio-video).
This means that Puppeteer does not support licensed formats such as AAC or
H.264. (However, it is possible to force Puppeteer to use a
separately-installed version Chrome instead of Chromium via the
[`executablePath` option to `puppeteer.launch`](./api/puppeteer.launchoptions.executablepath).
You should only use this configuration if you need an official release of
Chrome that supports these media formats.)
- Since Puppeteer (in all configurations) controls a desktop version of
Chromium/Chrome, features that are only supported by the mobile version of
Chrome are not supported. This means that Puppeteer
[does not support HTTP Live Streaming (HLS)](https://caniuse.com/#feat=http-live-streaming).
2022-07-01 11:52:39 +00:00
#### Q: I am having trouble installing / running Puppeteer in my test environment. Where should I look for help?
We have a
[troubleshooting](https://pptr.dev/troubleshooting)
guide for various operating systems that lists the required dependencies.
2022-07-01 11:52:39 +00:00
#### Q: Chromium gets downloaded on every `npm ci` run. How can I cache the download?
The default download path is `node_modules/puppeteer/.local-chromium`. However,
you can change that path with the `PUPPETEER_DOWNLOAD_PATH` environment
variable.
2022-07-01 11:52:39 +00:00
Puppeteer uses that variable to resolve the Chromium executable location during
launch, so you dont need to specify `PUPPETEER_EXECUTABLE_PATH` as well.
2022-07-01 11:52:39 +00:00
For example, if you wish to keep the Chromium download in `~/.npm/chromium`:
```sh
export PUPPETEER_DOWNLOAD_PATH=~/.npm/chromium
npm ci
# by default the Chromium executable path is inferred
# from the download path
npm test
# a new run of npm ci will check for the existence of
# Chromium in ~/.npm/chromium
npm ci
```
#### Q: I have more questions! Where do I ask?
There are many ways to get help on Puppeteer:
- [bugtracker](https://github.com/puppeteer/puppeteer/issues)
- [Stack Overflow](https://stackoverflow.com/questions/tagged/puppeteer)
Make sure to search these channels before posting your question.