player: window.__hf from @hyperframes/shader-transitions makes an src embed reject its own composition
メンテナーはふだん 1 日以内に返信
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 70/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- html, typescript
調査の方向性
Start by serving the reproduction folder over HTTP and opening host.html, comparing the ready and error events from comp-clean.html and comp-shader.html. Then trace the player’s src runtime probe and timeline adapter decision; done means both embedded compositions report ready with duration 10 instead of the shader case timing out.
索引モデルが issue の本文から書いたものです。
説明
Summary
<hyperframes-player src="..."> treats the mere existence of window.__hf in the composition
frame as "the core runtime is present". But @hyperframes/shader-transitions — the sibling
package, at the same version — creates that global itself at the end of HyperShader.init():
// @hyperframes/shader-transitions 0.8.41, dist/index.global.js
let gr = window;
return gr.__hf = gr.__hf || {}, gr.__hf.shaderTransitionsReady = Qo, ...
So any composition that uses shader transitions and registers its own timeline
(window.__timelines) — i.e. an authored GSAP composition, not one bundled by the CLI — can never
be played through the player when loaded with src. The probe:
- sees
hasRuntime = !!(win.__hf || win.__player)→true, so it never injects the runtime
(we()returns false); and hasRuntimeBridge()→true, so_resolveDirectTimelineAdapterFromWindow()returnsnull
and the direct-timeline adapter is refused.
Nothing is ever resolved, and 8 s later the element emits
error: "Composition timeline not found after 8s". The frame stays black.
window.__hf is a namespace, not a bridge — shader-transitions only ever augments it (it polls
for window.__hf.seek and warns "the engine bridge did not initialize" when the core runtime is
absent). The presence check should be for the bridge itself (__player, or a callable
__hf.seek), not for the object.
Reproduction
Two identical compositions; the only difference is the three lines shader-transitions would have
run. No GSAP needed — the stub has exactly the shape the player duck-types for.
timeline.js
window.__timelines = { main: (function () {
var t = 0;
return {
duration: function () { return 10; },
time: function (v) { if (v === undefined) return t; t = v; return this; },
seek: function (v) { t = v; return this; },
play: function () { return this; },
pause: function () { return this; },
};
})() };
comp-clean.html
<!doctype html><html><head><meta charset="utf-8"></head><body>
<div id="root" data-composition-id="main" data-width="1080" data-height="1920"></div>
<script src="timeline.js"></script>
</body></html>
comp-shader.html — identical, plus what HyperShader.init() leaves behind:
<!doctype html><html><head><meta charset="utf-8"></head><body>
<div id="root" data-composition-id="main" data-width="1080" data-height="1920"></div>
<script>
window.__hf = window.__hf || {};
window.__hf.shaderTransitionsReady = Promise.resolve();
</script>
<script src="timeline.js"></script>
</body></html>
host.html
<script src="https://cdn.jsdelivr.net/npm/@hyperframes/[email protected]/dist/hyperframes-player.global.js"></script>
<hyperframes-player id="a" src="comp-clean.html" width="1080" height="1920"></hyperframes-player>
<hyperframes-player id="b" src="comp-shader.html" width="1080" height="1920"></hyperframes-player>
<script>
for (const id of ["a", "b"])
for (const type of ["ready", "error"])
document.getElementById(id).addEventListener(type, (e) =>
console.log(id, type, e.detail));
</script>
Serve the folder over http and open host.html.
Actual
a ready {duration: 10}
b error {message: "Composition timeline not found after 8s"}
Expected
Both report ready. A composition does not stop being playable because it also uses
@hyperframes/shader-transitions.
Environment
@hyperframes/player0.8.41,@hyperframes/shader-transitions0.8.41,hyperframes0.8.41- Chromium 141, Linux
Notes
The same compositions render correctly with hyperframes render, because the CLI injects the core
runtime into the document before loading it — window.__player then exists and the player takes
the runtime path. The failure is specific to embedding an authored composition with src.
- 主要言語
- TypeScript
- スター
- 54.1k
- フォーク
- 4.9k
- 平均マージ
- 7時間 18分
- マージ済み PR(30日)
- 784
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
heygen-com/hyperframes のほかの issue
-
Docs: clarify that "Enable auto-update" is only available in the Claude Code terminal (CLI) /plugin UI対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
heygen-com/hyperframes#5027 ·
メンテナーはふだん 1 日以内に返信
-
fix(producer): propagate useGpu to HDR layered streaming encoder対応中かも @Monster-GM が 2 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 87/100
heygen-com/hyperframes#5002 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
heygen-com/hyperframes#4702 · コメント 1 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Studio catalog prompt editor has no accessible name対応中かも @lorenzozanee が 13 日前に担当しました。 オープンbug difficulty/easy triage/ready
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
heygen-com/hyperframes#4384 ·
メンテナーはふだん 1 日以内に返信
-
lint: validate composition variables declared on supported root elements再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンbug difficulty/easy triage/ready
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
heygen-com/hyperframes#4383 ·
メンテナーはふだん 1 日以内に返信
heygen-com/hyperframes の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
nats-io/nats.docs.v2#101 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
profullstack/ugig.net#601 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
github/codeql-action#4202 ·
メンテナーはふだん 1 日以内に返信
-
agents: formatReport/reportOrigin only importable through an entry that loads every runtime (~1.5 s)オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信