fix(engine): suppress font-load 404s by checking console location URL#313
Merged
jrusso1020 merged 1 commit intomainfrom Apr 18, 2026
Merged
fix(engine): suppress font-load 404s by checking console location URL#313jrusso1020 merged 1 commit intomainfrom
jrusso1020 merged 1 commit intomainfrom
Conversation
Chrome's "Failed to load resource" message text does not include the failing URL — it's only on msg.location().url. The previous filter in frameCapture.ts only checked msg.text(), so every font 404 (e.g. Google Fonts <link> tags in sandboxed render environments) fell through to the "[non-blocking]" prefix instead of being suppressed. Extract the classifier into isFontResourceError() and match against both text and location.url, and extend the extension match to .ttf/.otf. Adds a unit test covering the URL-in-location, URL-in-text, and non-font cases. This is a targeted fix for the render-output noise that PR #311 attempted to address by adding a ~120-entry SYSTEM_FONTS skip list. That approach silently shadowed existing FONT_ALIASES (arial→inter, helvetica→inter, courier new→jetbrains-mono, segoe ui→roboto, etc.) and changed render output on Linux fleets that don't have those fonts installed. Fixing the console-log filter here suppresses the noise without changing any font resolution behavior. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
miguel-heygen
approved these changes
Apr 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
In headless render environments, every font-load 404 appears in the render output as
[non-blocking] Failed to load resource: …noise — the exact symptom that PR #311 was targeting:The existing filter in
packages/engine/src/services/frameCapture.tswas supposed to suppress these (see the comment at line 153-154: "Suppress font-loading 404s entirely. These are expected…"), but it doesn't actually work:Chrome's console message
text()for a failed resource is just"Failed to load resource: net::ERR_FAILED"or"Failed to load resource: the server responded with a status of 404 (Not Found)"— the URL is not in the text, it's onmsg.location().url. So the regex never matches and every font 404 falls through to the[non-blocking]prefix.Reproducer
The old regex test against
textreturnsfalse, so the event is logged. Verified locally with a minimal Puppeteer reproducer.Fix
Extract the classifier into a testable
isFontResourceError(type, text, locationUrl)function and match against bothtextandlocationUrl. Also extend the extension set to.ttfand.otf.This is a targeted fix for the same noise PR #311 was after, without changing any font-resolution behavior.
Why not the SYSTEM_FONTS approach in PR #311
PR #311 adds a ~120-entry
SYSTEM_FONTSskip set toextractRequestedFontFamilies(). It silently shadows entries already inFONT_ALIASES:arial → interhelvetica,helvetica neue,helvetica bold → intercourier,courier new → jetbrains-monosegoe ui → robotoarial black,futura → montserratWith that PR applied, those aliases become dead code because
extractRequestedFontFamiliesskips the font beforebuildFontFaceCssever runs. On render fleets (e.g.Dockerfile.test—fonts-liberation/fonts-dejavu-core/fonts-noto-*, no Arial/Helvetica/SF Pro/Segoe UI/Tahoma installed), compositions that previously rendered with the aliased web font would shift to whatever fontconfig substitutes (Liberation Sans/Mono). That's a silent visual regression for existing fixtures such aspackages/producer/tests/style-15-prod/src/compositions/hero_moment.htmlwhich uses"Helvetica Neue", Helvetica, Arial, sans-serif.It also misidentifies the root cause:
Courier NewandCourierare already inFONT_ALIASESand never reach Google Fonts, so the 404s attributed to them in that PR's description aren't coming from Path 2 inbuildFontFaceCss. They're the generic<link rel="stylesheet" href="fonts.googleapis.com/…">tag (emitted bypackages/core/src/generators/hyperframes.ts:104-107) failing in a sandbox, which the broken filter above was supposed to hide.Testing
packages/engine/src/services/frameCapture.test.tswith 10 cases:location.urlbun run --filter @hyperframes/engine test→ 52/52 pass (5 files)bunx oxlint/bunx oxfmt --checkclean on changed filesVerified behavior
Before fix, reproducer shows:
After fix, the same event matches the filter and is suppressed.
🤖 Generated with Claude Code