[1.x] fix: add xslt polyfill so forum continues to boot on browsers without XSLT#4644
Merged
Conversation
… XSLT Backports the 2.x polyfill (#4359) for the 1.8 line. Chrome disabled XSLT in Beta from 145 (Dec 2025) and Stable from 158 (Nov 2026); without the polyfill, s9e/TextFormatter's `new XSLTProcessor` at parser-init time throws a ReferenceError that prevents forum.js from booting on those browsers. A ~200-byte detector is emitted into the document <head>. It tries to construct an XSLTProcessor; on failure it document.write()s a script tag pointing at the polyfill bundle. document.write of a script tag during HTML parsing blocks the parser until the polyfill loads, so window.XSLTProcessor is in place before forum.js runs. The polyfill is published into the flarum-assets disk by assets:publish and resolved through the disk's own ->url(), so installs that serve assets from a remote bucket / CDN get the right URL. To stay patch-release-safe, the FilesystemFactory is resolved via the container inside makeXsltPolyfillLoader() rather than added to the Document constructor — same pattern Document already uses for TitleDriverInterface.
imorland
added
dependencies
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
1 participant
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.
Summary
Backports #4359 to the 1.8 line as a patch (1.8.17). Adds an XSLT polyfill so Flarum continues to work end-to-end on browsers that have removed native XSLT support.
Chrome disabled XSLT by default in the Beta channel from version 145 (Dec 2025) and is removing it from Stable in version 158 (Nov 2026). Firefox has signalled it will follow. Without a polyfill,
forum.jsfails to initialize in those browsers — s9e/TextFormatter referencesXSLTProcessorduring parser init, throws aReferenceError, and takes the entire app boot down with it. Concretely this means:tags,links, etc.) throws in the consoleThis is a hard breakage, not a degraded UX, and applies to all users on the affected browser versions — not just those who open the composer. With 1.x EOL set to 31 December 2026, the 1-2 month window where 1.x users would otherwise sit on a broken Chrome stable release justifies shipping a patch fix.
How it works
A small (~200 byte) detector is emitted into the document
<head>. It triesnew XSLTProcessor(); on success it returns immediately. On failure (browser has removed XSLT) itdocument.write()s a<script src=\"…/xslt-polyfill/xslt-polyfill.min.js\">tag. Becausedocument.writeof a script tag during HTML parsing inserts it inline, the parser blocks until the polyfill loads — guaranteeingwindow.XSLTProcessoris in place beforeforum.jsexecutes.The polyfill URL is resolved against the
flarum-assetsdisk, so it's correct on installs that serve assets locally and on those backed by a remote bucket / CDN. The polyfill (xslt-polyfill^1.0.21) is published into the assets disk duringassets:publish, alongside its lazily-fetcheddist/xslt-wasm.jscompanion. Browsers with working native XSLT never download either file — only the inline detector.1.x-specific design choice — no constructor change
The 2.x PR added
FilesystemFactoryas a constructor argument onFrontend\Document. For a 1.x patch release that's off the table, so the 1.x port resolves it via the container insidemakeXsltPolyfillLoader()— the same patternFrontend\Documentalready uses forTitleDriverInterface(carrying its own// @todo v2.0 inject as dependency insteadcomment). No public API changes.Why this approach (vs. inlining)
The polyfill is large (~510 KB gzipped). Inlining it into
forum.jsfor every visitor — including the majority on browsers with working XSLT — would roughly triple the JS payload on every page load. Lazy-loading via the<head>detector restricts the cost to affected browsers and keeps the artifact cacheable as a separate hashed asset.Operator note: CORS for remote
flarum-assetsOperators serving the
flarum-assetsdisk from a different origin (S3, CDN, etc.) must allow CORS from their forum origin to the assets origin. The polyfill's bootstrap loads via<script src>(not CORS-checked), but its WASM sibling (dist/xslt-wasm.js) is fetched viafetch()from inside the polyfill, which is subject to CORS. Without the right CORS headers on the assets bucket, the WASM fetch fails and the polyfill silently doesn't install. Same requirement that already applies to web fonts and any other cross-origin asset; just worth being explicit since this PR adds a new file that usesfetch.Temporary measure
The polyfill is a stop-gap until s9e/TextFormatter ships an XSLT-free implementation: s9e/TextFormatter#250. Once that lands, the detector and asset publishing can be removed.
Test plan
XsltPolyfill::findSource()and::version()<\/script>split is in placeassets:publish— both polyfill files copied with correct relative layoutforum.jsboots, store types register, extensions initialize, live preview renders