Summary
<hyperframes-player> accepts a runtime-src attribute, and validates it carefully (http/https,
same-origin or loopback). But it is only ever read on the srcdoc path:
function H(r, e) { return qe(It(e, ...), Pt(r)); } // srcdoc -> honours runtime-src (Pt)
function F(r, e) { return Lt(e, ...); } // src -> URL params onlyThe probe that injects the runtime into an src iframe uses the module constant instead, with no
access to the host element:
var k = "https://cdn.jsdelivr.net/npm/@hyperframes/core@0.8.41/dist/hyperframe.runtime.iife.js";
_injectRuntime() {
this._runtimeInjected = true;
const t = doc.createElement("script");
t.src = k; // <- always the CDN
(doc.head || doc.documentElement).appendChild(t);
}So an src embed cannot be given a local runtime. On an offline or air-gapped machine, or behind
a script-src 'self' CSP, the injection silently fails (it is inside a bare try {} catch {}),
__hf never appears, and the element eventually emits
error: "Composition timeline not found after 8s".
Reproduction
comp-nested.html — a [data-composition-src] child makes the probe inject immediately:
<!doctype html><html><head><meta charset="utf-8"></head><body>
<div id="root" data-composition-id="main" data-width="1080" data-height="1920">
<div data-composition-src="child.html" data-start="0" data-duration="5"></div>
</div>
</body></html>host.html, served over http from the same origin as a local copy of the runtime:
<script src="https://cdn.jsdelivr.net/npm/@hyperframes/player@0.8.41/dist/hyperframes-player.global.js"></script>
<hyperframes-player src="comp-nested.html" runtime-src="/local-runtime.js"
width="1080" height="1920"></hyperframes-player>Actual
The network panel shows
GET https://cdn.jsdelivr.net/npm/@hyperframes/core@0.8.41/dist/hyperframe.runtime.iife.js 200
and no request for /local-runtime.js. runtime-src passes the element's own validation and is
still ignored.
Expected
src and srcdoc resolve the runtime the same way: runtime-src when it is set and valid, the
jsDelivr default otherwise. Concretely, pass the resolved URL into the probe (it is already
computed by Pt(host)) instead of closing over the module constant, so an embed can serve its own
pinned copy.
Two smaller things that would help either way:
- the injected
<script> has no onerror, so a blocked or 404 runtime is indistinguishable from
a slow one — the element just times out after 8 s with a message about the timeline;
- documenting
runtime-src as srcdoc-only would at least make the current behaviour discoverable.
Environment
@hyperframes/player 0.8.41, Chromium 141, Linux
Why it matters
A local review tool that embeds staged projects has to reach a CDN for every composition it opens,
or pre-inject the runtime into the served HTML itself (which is what we now do) — even though the
exact matching runtime is already sitting in node_modules/hyperframes/dist/.
Summary
<hyperframes-player>accepts aruntime-srcattribute, and validates it carefully (http/https,same-origin or loopback). But it is only ever read on the
srcdocpath:The probe that injects the runtime into an
srciframe uses the module constant instead, with noaccess to the host element:
So an
srcembed cannot be given a local runtime. On an offline or air-gapped machine, or behinda
script-src 'self'CSP, the injection silently fails (it is inside a baretry {} catch {}),__hfnever appears, and the element eventually emitserror: "Composition timeline not found after 8s".Reproduction
comp-nested.html— a[data-composition-src]child makes the probe inject immediately:host.html, served over http from the same origin as a local copy of the runtime:Actual
The network panel shows
and no request for
/local-runtime.js.runtime-srcpasses the element's own validation and isstill ignored.
Expected
srcandsrcdocresolve the runtime the same way:runtime-srcwhen it is set and valid, thejsDelivr default otherwise. Concretely, pass the resolved URL into the probe (it is already
computed by
Pt(host)) instead of closing over the module constant, so an embed can serve its ownpinned copy.
Two smaller things that would help either way:
<script>has noonerror, so a blocked or 404 runtime is indistinguishable froma slow one — the element just times out after 8 s with a message about the timeline;
runtime-srcas srcdoc-only would at least make the current behaviour discoverable.Environment
@hyperframes/player0.8.41, Chromium 141, LinuxWhy it matters
A local review tool that embeds staged projects has to reach a CDN for every composition it opens,
or pre-inject the runtime into the served HTML itself (which is what we now do) — even though the
exact matching runtime is already sitting in
node_modules/hyperframes/dist/.