Open
Description
Is your feature request related to a problem? Please describe.
When running browser automation in a non-GUI environment (e.g., Linux servers, Docker containers), since current tools start Chrome/Chromium in "headed mode" by default, it will try to connect to a local X Server or a remote debug port. Causes errors such as startup failure, ECONNREFUSED, or page load timeout. I often needed to install additional Xvfb or VNC to get the automation scripts to run, increasing deployment and maintenance costs.
Describe the solution you’d like
- Added a 'headless' (Boolean) option to the browser startup parameter, which can be selected by the user depending on the environment
- When 'headless: true', automatically add standard headless startup arguments such as' --headless ', '--disable-gpu', '--no-sandbox' to the command line
- If not specified, keep the existing behavior (with header mode) and make it clear in the documentation how to switch
- Also allows headless mode to be enabled globally via an environment variable such as' BROWSER_HEADLESS=true '
Describe alternatives you’ve considered
- Manually install and configure virtual display environments such as Xvfb, XFCE, x11vnc in CI/CD or Docker images
- Hardcoded 'chromium.launch({headless: true})' in the script, but not consistent and inconsistent with the tool's default behavior
- Use Puppeteer or another framework to manage headless mode separately, but with increased learning costs and dependencies
Additional context
- Server environment: Debian Bookworm slim Docker container, no system X Server
- Typical errors: 'BrowserType.connect_over_cdp: connect ECONNREFUSED ::1:9222', 'Page load failed'
- reference documentation: [Playwright Headless Mode] (https://playwright.dev/docs/api/class-browsertype#browsertypelaunch)
- If headless support is built in, users can switch between various environments with a single argument, greatly simplifying deployment.