[Bug]: Executable path is not properly generated when using PUPPETEER_BROWSER_REVISION=stable

[alexandcote]

Minimal, reproducible example

// Set `PUPPETEER_BROWSER_REVISION` to `stable`
// export PUPPETEER_BROWSER_REVISION=stable
// Run `npm install puppeteer --save`

import puppeteer from 'puppeteer'

(async () => {
    const browser = await puppeteer.launch()
    const page = await browser.newPage()
    try {
        await page.goto('https://google.com')
        await browser.close()
    } catch (error) {
        console.log(error)
    }
    await browser.close();
})();

Error string

The executablePath uses stable while the path contains the actual browser revision.

Bug behavior

• Flaky
• PDF

Background

No response

Expectation

The Executable Path should be generated using the actual installed browser revision.

Reality

The executable path tries to get the stable revision and will never exist.

I was able to temporarily fix the problem using this function:

async function getExecutablePath() {
  const browsers = await getInstalledBrowsers({
    cacheDir: process.env.PUPPETEER_CACHE_DIR || '',
  });

  if (browsers.length === 0) {
    throw new Error('Could not find a browser to launch');
  }

  const browser = browsers[browsers.length - 1];
  return browser.executablePath;
}

Puppeteer configuration file (if used)

No response

Puppeteer version

21.10.0

Node version

20.11.0

Package manager

npm

Package manager version

10.2.4

Operating system

Windows

[github-actions]

This issue was not reproducible. Please check that your example runs locally and the following:

• Ensure the script does not rely on dependencies outside of puppeteer and puppeteer-core.
• Ensure the error string is just the error message.

  • Bad:

    Error: something went wrong
      at Object.<anonymous> (/Users/username/repository/script.js:2:1)
      at Module._compile (node:internal/modules/cjs/loader:1159:14)
      at Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
      at Module.load (node:internal/modules/cjs/loader:1037:32)
      at Module._load (node:internal/modules/cjs/loader:878:12)
      at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
      at node:internal/main/run_main_module:23:47

  • Good: Error: something went wrong.

• Ensure your configuration file (if applicable) is valid.
• If the issue is flaky (does not reproduce all the time), make sure 'Flaky' is checked.
• If the issue is not expected to error, make sure to write 'no error'.

Once the above checks are satisfied, please edit your issue with the changes and we will
try to reproduce the bug again.

---

Analyzer run

[OrKoN]

@alexandcote stable is not a proper browser revision/version. Puppeteer expects a specific revision, not an alias. Previously, revisions were numeric and nowadays they are version numbers. Puppeteer also expects the user to install the revision that is requested:

npx puppeteer browsers install chrome@119.0.6045.105
npx puppeteer browsers install chrome-headless-shell@119.0.6045.105
export PUPPETEER_BROWSER_REVISION=119.0.6045.105
# now any launch function will use 119.0.6045.105 if nothing else is provided via launch arguments

[OrKoN]

Also, if you need the stable version, we recommend using the version bundled with Puppeteer. Resolving aliases at launch time is unfortunately not very reliable so it is out of scope for Puppeteer for now.

[alexandcote]

The weird part is if you only specify PUPPETEER_BROWSER_REVISION=stable the stable version is installed properly but the executablePath is not generated properly. While you can do npx @puppeteer/browsers install chrome@stable I believe 🤔

[OrKoN]

@alexandcote yes, it's because resolving the stable label to a specific version requires a network call to figure out which version is currently stable and that can be quite unreliable so you probably don't want that when you launch the browser. This PUPPETEER_BROWSER_REVISION variable was there before Chrome for Testing and before it was possible to install versions by alias so I guess this unintended side effect of this new ability that we try to resolve configuration during the installation.

[alexandcote]

@OrKoN I understand thanks for the context 👍🏻 😄

Do you see any value in adding a feature to allow consumers to always use the last stable version?

I'm proposing this because when a security issue happens in Chrome, consumers have to wait for a Puppeteer update and update the consumer service (in our case in many different services).

Alternatively, we could install Chrome manually and skip the installation during Puppeteer installation. This required more setup.

What I'm proposing is if PUPPETEER_BROWSER_REVISION=stable|latest|beta is used, Puppeteer install the browser like it does today in: <CACHE>/chrome/<DISTRO>-<REVISION> but create a symlink so <CACHE>/chrome/<DISTRO>-<stable|latest|beta> point to the installed revision. This will allow the executable path to work properly and will require consumers to only set the PUPPETEER_BROWSER_REVISION to use the stable version.

What do you think 😄 ?

[OrKoN]

Good suggestion, I would probably go in the direction of adding metadata to the browser folders though.