Skip to content

Add host-gated site-specific JS content patches, fix MDN permalink - #395

Merged
benoit74 merged 1 commit into
mainfrom
benoit74/mdn-permalink-site-patch
Nov 8, 2026
Merged

benoit74 merged 1 commit into
mainfrom
benoit74/mdn-permalink-site-patch

Conversation

@benoit74

@benoit74 benoit74 commented Nov 6, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • <interactive-example> (developer.mozilla.org's top "Try it" widget) renders its inner <mdn-play-runner> without the permalink attribute, so that component falls back to crypto.randomUUID() for a session-random id instead of the content-derived hash <mdn-live-sample-result> uses elsewhere on the same page (whose own template already always sets permalink). A fresh random id can never match anything captured in a WARC, so the widget always fails to load on replay — even though its initial, pre-edit code is just as content-stable as the other live-sample widgets that already work; only the id source differs.
  • Adds a small SITE_JS_PATCHES table to JsRewriter, keyed by exact hostname (the host of the article URL currently being rewritten, i.e. this JS file's own URL), applied before any other rewriting. Each entry pairs a cheap marker substring check with a regex patch, so the regex only ever runs on content that both matches the host and contains the marker.
  • Registers one entry for developer.mozilla.org that adds permalink to <interactive-example>'s three <mdn-play-runner> template variants (choices/console/tabbed).

Deliberately scoped as a content-level fix in the existing rewriting pipeline rather than patching WARC files at crawl time (discussed in openzim/warc2zim#327): the pipeline already hands JsRewriter clean, decoded JS text with no WARC/HTTP framing to worry about, and this follows the same precedent fuzzyRules.js already set for narrow, host-scoped quirk handling inside this general-purpose library.

Verified against the real captured MDN chunk, not just synthetic test fixtures: 3 patches applied when rewritten as developer.mozilla.org, 0 when rewritten as any other host — including lookalikes like developer.mozilla.org.evil.example and notdeveloper.mozilla.org, confirming exact-hostname matching (not a substring/prefix/suffix check) is what gates this.

Fixes #394, found via openzim/warc2zim#327.

@benoit74 benoit74 self-assigned this Nov 6, 2026
@codecov

codecov Bot commented Nov 6, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (940d1b2) to head (b8e7c59).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #395   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           42        42           
  Lines         2937      2947   +10     
  Branches       450       452    +2     
=========================================
+ Hits          2937      2947   +10     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

developer.mozilla.org's top "Try it" widget (<interactive-example>)
renders its inner <mdn-play-runner> without the `permalink`
attribute, so that component falls back to crypto.randomUUID() for a
session-random id instead of the content-derived hash
<mdn-live-sample-result> uses elsewhere on the same page (whose own
template already always sets `permalink`). A fresh random id can
never match anything captured in a WARC, so the widget always fails
to load on replay, even though its initial, pre-edit code is just as
content-stable as the other live-sample widgets that already work -
only the id source differs.

Add a small SITE_JS_PATCHES table to JsRewriter, keyed by exact
hostname (the host of the article URL currently being rewritten),
applied before any other rewriting. Each entry pairs a marker
(cheap substring check) with a regex patch, so the regex only ever
runs on content that both matches the host AND contains the marker.
Register one entry for developer.mozilla.org that adds `permalink`
to <interactive-example>'s three <mdn-play-runner> template variants.

Verified against the real captured MDN chunk: 3 patches applied when
rewritten as developer.mozilla.org, 0 when rewritten as any other
host (including lookalikes like
developer.mozilla.org.evil.example, where exact-hostname matching
rather than a substring check prevents any match).

Found via openzim/warc2zim#327. (#394)
@benoit74
benoit74 force-pushed the benoit74/mdn-permalink-site-patch branch from abf0025 to b8e7c59 Compare November 8, 2026 20:47
@benoit74
benoit74 merged commit d1deb81 into main Nov 8, 2026
8 checks passed
@benoit74
benoit74 deleted the benoit74/mdn-permalink-site-patch branch November 8, 2026 20:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

developer.mozilla.org's "Try it" widget always 404s on replay (missing permalink attribute)

1 participant