jest-puppeteer icon indicating copy to clipboard operation
jest-puppeteer copied to clipboard

userDataDir must be specified in `args` outside `launch`, or else browser crashes

Open alisha opened this issue 1 year ago • 4 comments
trafficstars

🐛 Bug Report

At first I thought this was a bug where I couldn't specify the userDataDir parameter, as my browser would always crash and my tests would never run. I found out how to specify this parameter correctly and have the tests run, but it's unintuitive. I think this should either be documented, or be fixed to be more intiutive.

If your config file looks like this:

// jest-puppeteer.config.cjs

/** @type {import('jest-environment-puppeteer').JestPuppeteerConfig} */
module.exports = {
    launch: {
      headless: false,
      userDataDir: "./user_data_dir",
    },
};

Or like this:

// jest-puppeteer.config.cjs

/** @type {import('jest-environment-puppeteer').JestPuppeteerConfig} */
module.exports = {
    launch: {
      headless: false,
        args: [
            '--user-data-dir=./user_data_dir',
        ]
    },
};

The browser will launch, immediately crash, and the tests are never run. I also get this error message:

Error: Jest: Got error running globalSetup - jest-bug-repro/node_modules/jest-environment-puppeteer/setup.js, reason: Failed to launch the browser process!


TROUBLESHOOTING: https://pptr.dev/troubleshooting

    at ChildProcess.onClose (jest-bug-repro/node_modules/@puppeteer/browsers/lib/cjs/launch.js:310:24)
    at ChildProcess.emit (node:events:539:35)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:291:12)

However, if you have the following config file (where args is outside of launch):

// jest-puppeteer.config.cjs

/** @type {import('jest-environment-puppeteer').JestPuppeteerConfig} */
module.exports = {
    launch: {
      headless: false,
    },
    args: [
        '--user-data-dir=./user_data_dir',
    ]
};

It will work as expected. Note that if you want to specify other args for puppeteer, you must have another args array inside launch (like the second config file I showed).

To Reproduce

Use either of these config files:

// jest-puppeteer.config.cjs

/** @type {import('jest-environment-puppeteer').JestPuppeteerConfig} */
module.exports = {
    launch: {
      headless: false,
      userDataDir: "./user_data_dir",
    },
};

Or

// jest-puppeteer.config.cjs

/** @type {import('jest-environment-puppeteer').JestPuppeteerConfig} */
module.exports = {
    launch: {
      headless: false,
        args: [
            '--user-data-dir=./user_data_dir',
        ]
    },
};

Expected behavior

The browser exits only after tests are run. I would also expect the second config file showed (where launch has args, which in turn has --user-data-dir=...) to work.

Link to repl or repo (highly encouraged)

https://github.com/alisha/jest-bug-repro

The jest-puppeteer.config.cjs file contains 4 versions of a config file, 3 of which are commented out so you can run it. The first 2 versions reproduce the issue, while the last two versions work.

Run npx envinfo --system --binaries --npmPackages expect-puppeteer,jest-dev-server,jest-environment-puppeteer,jest-puppeteer,spawnd --markdown --clipboard

Paste the results here:

## System:
 - OS: macOS 13.5.2
 - CPU: (10) arm64 Apple M1 Max
 - Memory: 2.58 GB / 64.00 GB
 - Shell: 3.2.57 - /bin/bash
## Binaries:
 - Node: 17.9.1 - ~/.nvm/versions/node/v17.9.1/bin/node
 - npm: 8.11.0 - ~/.nvm/versions/node/v17.9.1/bin/npm
## npmPackages:
 - jest-puppeteer: ^10.0.1 => 10.0.1

alisha avatar Apr 05 '24 18:04 alisha

Actually, I realized that the proposed fix I mentioned suppresses the error and lets the tests be run, but the user profile is not stored in the specified directory. So, the proposed fixes don't actually work.

alisha avatar Apr 05 '24 20:04 alisha

Update: was actually able to solve this issue by modifying my Jest config file to have maxWorkers set to 1. I'm now able to specify the userDataDir parameter in the launch options, and have tests run and user profile state persisted.

I realized this because when I specified the userDataDir parameter (set to ./tmp) with headless set to true, I got this error:

Error: Jest: Got error running globalSetup - node_modules/jest-environment-puppeteer/setup.js, reason: Failed to launch the browser process! undefined
[83873:259:0405/141345.099847:ERROR:process_singleton_posix.cc(335)] Failed to create tmp/SingletonLock: File exists (17)
[83873:259:0405/141345.106931:ERROR:chrome_main_delegate.cc(590)] Failed to create a ProcessSingleton for your profile directory. This means that running multiple instances would start multiple browser processes rather than opening a new window in the existing process. Aborting now to avoid profile corruption.

So it seems like having multiple Jest workers creates an issue with setting up a shared user profile. For now, I think it would be great if this issue is documented; I'm not sure what the fix for this would be

alisha avatar Apr 05 '24 21:04 alisha

Hello @alisha, I am not sure it's relative to jest-puppeteer itself then. So what is the issue exactly? Because this option is documented in Puppeteer: https://pptr.dev/api/puppeteer.browserlaunchargumentoptions

gregberge avatar Apr 08 '24 10:04 gregberge

Sorry the initial bug report was unclear -- I realized what the actual issue (mentioned here) is after submitting the initial report.

The actual issue is how Jest and Puppeteer integrate together. If you have multiple Jest workers, they will all launch simultaneous browser processes. If you specify a single user data directory in your jest-puppeteer config, all of these processes will share the same user data directory; and Chromium will abort the processes because of potential file system concurrency issues. As a result, the user sees a generic error message and their tests never run.

The fix is simple: use a single Jest worker if you need to specify the user data directory. I think it would be great for this to be documented somewhere, as I had to spend a lot of time to figure this out, and I'd love to spare other users that time spent debugging.

alisha avatar Apr 08 '24 18:04 alisha