Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

fix(browse): honor GSTACK_CHROMIUM_PATH in headless launch()#1968

Open
shofel wants to merge 1 commit into
garrytan:main from
shofel:fix-headless-chromium-path
Open

fix(browse): honor GSTACK_CHROMIUM_PATH in headless launch() #1968
shofel wants to merge 1 commit into
garrytan:main from
shofel:fix-headless-chromium-path

Conversation

@shofel

@shofel shofel commented Jun 11, 2026

Copy link
Copy Markdown

Problem

The headed launchPersistentContext() path honors GSTACK_CHROMIUM_PATH, but the headless chromium.launch() path does not. There is no way to point headless rendering at a custom Chromium.

On NixOS this breaks make-pdf (and any headless screenshot/PDF flow): Playwright's bundled chrome-headless-shell is FHS-linked and can't load its shared libs, so the daemon fails to launch Chromium and make-pdf produces no output. Setting GSTACK_CHROMIUM_PATH to a system Chromium has no effect because the headless path ignores it.

Fix

Mirror the headed path: pass executablePath to chromium.launch() when GSTACK_CHROMIUM_PATH is set. Four lines, gated on the env var so default behavior is unchanged.

chromiumSandbox: shouldEnableChromiumSandbox(),
...(process.env.GSTACK_CHROMIUM_PATH ? { executablePath: process.env.GSTACK_CHROMIUM_PATH } : {}),

Verification

On NixOS with GSTACK_CHROMIUM_PATH pointing at a Nix-built ungoogled-chromium, make-pdf generate now renders a correct multi-element PDF (heading, bold, inline code, lists) — confirmed via pdftotext extraction and a rendered PNG. Without the patch the same setup fails at Chromium launch.

Note (separate issue)

make-pdf's browseClient binary discovery (argv[0]-based) misresolves for the Bun-compiled pdf binary and needs GSTACK_BROWSE_BIN pinned to reliably use the right daemon. That's independent of this change and not addressed here.

The headed launchPersistentContext() path already honors
GSTACK_CHROMIUM_PATH, but the headless chromium.launch() path did not.
On NixOS the bundled Playwright chrome-headless-shell is FHS-linked and
can't load its shared libs, so headless rendering (make-pdf, screenshots,
PDF export) fails with no way to override the binary. Mirror the headed
path: pass executablePath when GSTACK_CHROMIUM_PATH is set.

trunk-io Bot commented Jun 11, 2026

Copy link
Copy Markdown

Merging to main in this repository is managed by Trunk.

  • To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

Copy link
Copy Markdown
Contributor

Reviewed this — looks correct, nice tight fix.

The headed launchPersistentContext() path already honors GSTACK_CHROMIUM_PATH via executablePath (browser-manager.ts ~L490–566), but the headless chromium.launch() at ~L372 didn't, so this 4-line env-gated change closes a real and consistent gap (the NixOS headless make-pdf failure). Default behavior is unchanged since executablePath is only spread in when the env var is set, and it mirrors the existing headed handling exactly. No change requested from me.

One coordination heads-up: #1933 (GSTACK_CHROMIUM_ARGS / GSTACK_HTTP_CREDENTIALS) and #1915 (GSTACK_HEADED_NOGPU) also edit this same launch path, so whichever lands first will leave the others with a trivial conflict — might be worth sequencing the three.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

AltStyle によって変換されたページ (->オリジナル) /