andyearnshaw / docketeer

A tiny application that lets you use a dockerised browser for Puppeteer
The Unlicense
3 stars 1 forks source link

Browser process and docker container stay alive when `browser.close()` is called #1

Closed andyearnshaw closed 2 years ago

andyearnshaw commented 2 years ago

Tested with Karma (custom launcher for puppeteer) and @storybook/addon-storyshots-puppeteer. It works with puppeteer.attach() when the launch script is executed directly:

$ env DOCKETEER_IMAGE=browserless/chrome:latest ./launch.mjs --no-sandbox --remote-debugging-bind-address=0.0.0.0 --remote-debugging-port=9222 --headless
import puppeteer from "puppeteer";

const browser = await puppeteer.attach({
  browserWSEndpoint: "..." // copy and paste from output above
});

// Docker process ends
await browser.close();

It's only when puppeteer.launch() is used that the browser is not properly closed when browser.close() is called. The following puppeteer script should repro:

// test.mjs
import puppeteer from 'puppeteer';

const browser = await puppeteer.launch({
    dumpio: true,
    args: [
        "--remote-debugging-port=9222",
        "--no-sandbox",
        "--headless",
    ]
});

// Docker process does not end
await browser.close();
$ ./index.mjs browserless/chrome:latest node ./test.mjs 
andyearnshaw commented 2 years ago

This is caused by Puppeteer sending a SIGKILL to the Docketeer process when browser.close() is called following puppeteer.launch(). It only does this when the userDataDir option is not specified in the options to launch(), because it creates a temporary directory by default and it does not care about the browser gracefully exiting in this case as the OS will clean up the temp dir and it won't be used again.

v1.0.3 contains a workaround for this, see https://github.com/andyearnshaw/docketeer#known-issues. Any proper fix would require a change to puppeteer.