Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

gcp-cloud-run image pins Chrome 148, which drops `background-clip: text` glyphs inside layered children; the CLI's Chrome 152 paints them

Open Beginner friendly
  • Is something wrong?
#5,117 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@user-github-me is already working on this.

Since Oct 8, 2026.

  • #5207 by @user-github-me — open

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
84/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
docker, typescript
Domain
build-system

Research direction

Start at packages/gcp-cloud-run/Dockerfile and Dockerfile.test, where chrome-headless-shell is pinned to 148.0.7778.167; update both to 152.0.7977.30, the build packages/cli/src/browser/manager.ts already manages. Confirm the version is consistent with the CLI by reading manager.ts, then run the image build so its BeginFrame probe gates the new pin. Done when the Dockerfile build passes that probe and a Cloud Run image render matches a local render of the linked repro.

Written by the indexing model from the issue text.

Description

Describe the bug

packages/gcp-cloud-run/Dockerfile (and Dockerfile.test) pin [email protected]. That Chromium build leaves descendants with their own paint layer (transform, opacity, filter, position, will-change) out of a background-clip: text mask, so gradient text whose glyphs live in such a child is painted with its transparent fill and nothing else: the line is invisible in the render.

The CLI's managed Chrome (152.0.7977.30, packages/cli/src/browser/manager.ts) paints it, as does hyperframes preview in any current browser. So the same project renders differently on a workstation and on Cloud Run, and only the Cloud Run output is wrong.

This hits any split-text entrance (lines or words wrapped in divs that a GSAP tween translates, fades or blurs) applied to gradient text. The tween leaves a transform on each wrapper, which is enough.

Related: #2810 resolved the BeginFrame question for this exact pin, so I don't think BeginFrame is a reason to stay on 148. check flags the pattern as text_not_painted (transparent fill) on every Chrome, which matches the 148 output rather than what 150+ and browsers paint; that may be worth a look too.

Minimal reproduction

https://github.com/ArcadeHQ/hyperframes-repros/tree/patch/bg-clip-text-layered-child

One index.html, no scripts, no animation: two gradient lines, the second inside a child with transform: translateY(0).

Steps to reproduce

git clone -b patch/bg-clip-text-layered-child https://github.com/ArcadeHQ/hyperframes-repros
cd hyperframes-repros
npm run render -- --quality draft --output out/chrome-152.mp4            # CLI's managed Chrome: both lines

npx --yes @puppeteer/browsers install [email protected]
HYPERFRAMES_BROWSER_PATH=<path printed above> npm run render -- --quality draft --output out/chrome-148.mp4   # second line missing

ffmpeg -ss 0.5 -i out/chrome-152.mp4 -frames:v 1 out/chrome-152.png
ffmpeg -ss 0.5 -i out/chrome-148.mp4 -frames:v 1 out/chrome-148.png

The 148 render is what the @hyperframes/gcp-cloud-run image produces.

Expected behavior

Both lines render with the gradient, matching preview and a local render.

Actual behavior

On Chrome 148 only "Direct text" renders. The second line's box is still laid out, but nothing paints in it.

Frame at 0.5 s, CLI Chrome 152 (expected):

chrome-152

Same frame on Chrome 148 (the Cloud Run image):

chrome-148

Environment

  • hyperframes 0.8.134
  • Node v24.21.0, macOS arm64 (Apple M1 Pro)
  • Chrome: chrome-headless-shell 152.0.7977.30 (CLI managed) vs 148.0.7778.97 via HYPERFRAMES_BROWSER_PATH; Linux 148.0.7778.167 in the Cloud Run image shows the same
  • ffmpeg 9.0.2

npx hyperframes doctor from the repro checkout:

  ✓ Version          0.8.134 (latest)
  ✓ Node.js          v24.21.0 (darwin arm64)
  ✓ CPU              10 cores · Apple M1 Pro @ 2400MHz
  ✓ Memory           16.0 GB total
  ✓ FFmpeg           ffmpeg 9.0.2 at /opt/homebrew/bin/ffmpeg
  ✓ FFprobe          ffprobe 9.0.2 at /opt/homebrew/bin/ffprobe
  ✓ Chrome           cache: ~/.cache/puppeteer/chrome-headless-shell/mac_arm-154.0.8037.92/...
  ✗ Docker           Not found

Additional context

Requested fix: pin the gcp-cloud-run image (and Dockerfile.test) to the same build the CLI manages, 152.0.7977.30, so Cloud Run and workstation renders use one Chrome. The image build's BeginFrame probe gates that, and our render corpus passes on 152. Happy to send the one-line PR if useful.

Note for completeness: Chromium 150+ paints the layered child's glyphs but still in the clipping box's own space (no transform, opacity or filter applied to the mask), which Firefox does apply. That is a Chromium limitation, not a HyperFrames one, and is not what this issue asks to change.

Dominant language
TypeScript
Stars
54.1k
Forks
4.9k
Avg merge
7h 19m
Merged PRs (30d)
746

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from heygen-com/hyperframes

All issues in heygen-com/hyperframes

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.