* fix: test failing in headful
* fix: install Firefox for headful tests
* fix: skip favicon.ico requests in test
* fix: auth test in headful
* fix: disable NetworkTimeServiceQuerying
* fix: filter more favicon requests
* fix: network test with favicon
* fix: improve fixes
Puppeteer has problems handling navigations to pages that
are restored from the back-forward cache. Let's disable it
until we have the support and test coverage.
Issues: #8182
Some recent changes to allow arm64 environments (including M1 macs) to
launch a chromium installation successfully before arm-compatible builds
were downloadable prevented the usage of PUPPETEER_EXECUTABLE_PATH in
some environments. Currently, when the platform is not darwin and the
arch is arm64, an executable cannot be specified using the environment
variable.
Generally speaking, environment variables have highest precedence for
options such as this since they depend on system configuration.
These change:
1. allow the ENV variable to always be used when defined and not
specified in LaunchOptions (and when not puppeteer-core)
2. Retain the existing behavior of assuming /usr/bin/chromium-browser on
platforms like Ubuntu (exact if-conditions preserved to avoid any
breaking changes)
3. Add some tests for this particular portion of the code.
When the browser has been started and we have a valid reference lets make use of it instead of force-killing the process. A force kill should probably be the last resort in cleaning up the process.
This will help with Firefox as described on #7668 (comment).
When using a custom Firefox profile for Puppeteer the modified
preferences as present in prefs.js need to be reset once the
profile is no longer needed by Puppeteer. If not done this could
cause side-effects when the profile is used next time outside
of Puppeteer.
As ride-along fix the "--foreground" argument for Firefox will
only be used on MacOS because that's the only supported platform.
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`.
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
* 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>
This commit tidies up the quite confusing state of all the various types
required to launch a browser. As we saw when upgrading DevTools
(https://source.chromium.org/chromium/chromium/src/+/master:third_party/devtools-frontend/src/test/conductor/hooks.ts;l=77),
we had to define our launch options variable like so:
```ts
const opts: puppeteer.LaunchOptions & puppeteer.ChromeArgOptions & puppeteer.BrowserOptions = {
...
};
```
This commit fixes that by introducing `AllNodeLaunchOptions`, which is
defined as the intersection of all the above types.
Additionally, the types defined as `ChromeArgOptions` are actually used
for launching both Chrome and Firefox, so I have renamed them to
`BrowserArgOptions`, and therefore this change is breaking because
anyone using `ChromeArgOptions` in their types will need to switch.
BREAKING CHANGE: renamed type `ChromeArgOptions` to `BrowserLaunchArgumentOptions`
BREAKING CHANGE: renamed type `BrowserOptions` to `BrowserConnectOptions`
* fix(launcher): output correct error message for browser
When running `npm run release` today I got this error logged:
```
Error: Could not find browser revision 848005. Run "PUPPETEER_PRODUCT=firefox npm install" or "PUPPETEER_PRODUCT=firefox yarn install" to download a supported Firefox browser binary.
at ChromeLauncher.launch (/Users/jacktfranklin/src/puppeteer/lib/cjs/puppeteer/node/Launcher.js:80:27)
```
The error is only partially correct; I did have the browser revision
missing, but I needed the Chromium browser, not Firefox. It turns out
the logic in `Launcher.ts` didn't take this into account; it mistakenly
had been hardcoded to always log out the error as if the Firefox binary
was missing.
This PR updates the message depending on the browser:
Chrome error:
> Error: Could not find expected browser (chrome) locally. Run npm
> install or yarn install to download the correct Chromium revision
> (848005).
Firefox error:
> Error: Could not find expected browser (firefox) locally. Run
> "PUPPETEER_PRODUCT=firefox npm install" or "PUPPETEER_PRODUCT=firefox
> yarn install" to download a supported Firefox browser binary.
* Update src/node/Launcher.ts
Co-authored-by: Mathias Bynens <mathias@qiwi.be>
Co-authored-by: Mathias Bynens <mathias@qiwi.be>
Launching headless with a relative `userDataDir` hangs on Windows. Fix by calling `path.resolve` (idempotent) to add an absolute path instead in `defaultArgs`.
Issues: #3453
The `Launcher` class was serving two purposes:
1. Launch browsers
2. Connect to browsers
Number 1) only needs to be done in Node land, but 2) is agnostic; in a
browser version of Puppeteer we'll need the ability to connect over a
websocket to send commands back and forth.
As part of the agnostification work we needed to split the `Launcher` up
so that the connection part can be made agnostic. Additionally, I
removed dependencies on `https`, `http` and `URL` from Node, instead
leaning on fetch (via `node-fetch` if in Node land) and the browser
`URL` API (which was added to Node in Node 10).
By adding support for an environment variable `PUPPETEER_DOWNLOAD_PATH` it is possible to support downloading the browser binaries into a folder outside the `node_modules` folder. This makes it possible to preserve previously downloaded binaries in order to skip downloading them again.
* chore: enforce file extensions on imports
To make our output agnostic it should include file extensions in the
output, as per the ESM spec. It's a bit odd for Node packages but makes
it easier to publish a browser build.
* chore(docs): reduce warnings when generating docs
This is a bunch of small miscellaneous fixes that reduce the amount of
warnings logged when generating our new docs. The long term goal is to
get this list down to 0 warnings, but I'll do it in multiple PRs.
* satisfy doclint
These files will be used by both the web and node versions of Puppeteer.
Another name for this might be "core" but I don't want to cause
confusion with the puppeteer-core package that we publish at the moment.
This is another step towards making Puppeteer agnostic of environment
and being able to run in Node or a browser.
The files in the `node` directory are ones that would only be needed in
the Node build - e.g. the code that downloads and launches a local
browser instance.
The long term vision here is to have three folders:
* node - Node only code
* web - Web only code
* common - code that is shared
But rather than do that in one PR I'm going to split it up to make it
easier to review and deal with.
