bug: ルビータブで表示していたプログラムがコードタブ（ブロック）で消えることがある

[takaokouji]

概要

ルビータブで表示・編集していたプログラムが、コードタブ（ブロック）側で消えてしまうことがある、という不具合報告。間欠的に発生し、安定再現には至っていないが、ユーザー報告に加えてメンテナ側でも 1 度発生を確認したため、本格的に調査する。

特徴的なのは、ルビータブにはプログラムが残っているのに、コードタブのブロックだけが消えるという非対称な症状。報告者の手元でもルビータブにはプログラムが残っていた。

ユーザー報告

• フィードバック: 【修正済み】2026/05/30 14:44 [不具合報告] ルビー内に表示されているプログラムがコード内で消えている smalruby3-develop#91

• 報告内容（原文）:

  ルビー内に表示されているプログラムがコード内で消えている

再現状況

• 複数のユーザーから類似の報告あり
• メンテナの手元でも 1 回だけ 発生を確認。その後の再現確認では再発していない
• 現時点で安定した再現手順は未確立（間欠的に発生）

再現手順（仮説・現状まだ再現できていない）

tools/playwright-verify/ の調査スクリプトに、現時点で最有力と考えている再現シナリオをエンコードしてある。いずれもこの手順では手元でまだ再現できていない（= 仮説段階）。

repro-costume-clears-blocks.mjs（VM 注入でブロックを用意）

workspaceUpdate の発火回数・XML 内のトップブロック数・deleteBlock 呼び出しを計測しながら、以下を実行する:

1. スプライト 1 つにプログラム（event_whenflagclicked → motion_movesteps(10)）を用意し、コスチュームを 2 枚にする
2. コードタブを開く（baseline）
3. ルビータブ を開く（プログラムが Ruby として生成され、ルビータブ側に保持される状態を作る ＝ 報告者の状況に合わせる）
4. コードタブへ戻る
5. コスチュームタブ を開く
6. 2 枚目のコスチュームを選択（setCostume(1)）
7. コードタブへ戻り、ブロックが消えていないか確認

仮説: コスチューム切り替えに伴うタブ再構築・workspaceUpdate の過程で、ルビータブには残るのにブロックワークスペースが空で上書きされる経路があるのではないか。

repro-costume-realdrag.mjs（パレットからの実ドラッグ）

上記が VM 注入でブロックを作るのに対し、こちらはパレットからの実ドラッグでネイティブな Blockly ワークスペース状態を作ってから、「コスチュームタブ → 別コスチューム選択 → コードタブ」を行う。実ユーザーの操作に近い状態で再現するかを確認する目的。

現状

• 上記 2 シナリオを実行しても、手元ではブロック消失を再現できていない
• そのため、抜けている条件（特定のブロック構成 / ルビータブでの編集有無 / タイミング / 端末・ブラウザ差）を引き続き探る必要がある

想定される発生箇所・調査の出発点

ルビータブ ↔ コードタブ（Blockly ワークスペース）間の同期処理周辺が疑わしい。特にタブ切り替え時にワークスペースが再構築される過程でブロックが失われるパターンを重点的に調べる。

調査対象の候補:

• packages/scratch-gui/src/containers/ruby-tab.jsx — ルビータブ ↔ ブロック変換、タブ切り替えロジック
• packages/scratch-gui/src/lib/ruby-to-blocks-converter/ — Ruby → ブロック変換
• packages/scratch-gui/src/lib/ruby-generator/ — ブロック → Ruby 生成
• タブ切り替え時の workspaceUpdate / Blockly ワークスペース再構築タイミング（コスチューム/音タブからコードタブへ戻った際の getBBox() 問題など、既知の Playwright 固有挙動とは別に、実機での消失を確認する）

調査方針

1. 上記 repro スクリプトを足がかりに、ブロックが消失する具体的な操作シーケンス（抜けている条件）を特定する
2. ルビータブ ↔ コードタブの相互変換・タブ切り替え時に、空のプログラムでブロックワークスペースが上書きされる経路がないか確認する
3. 再現手順が確立できたら RED テスト（integration test）を追加し、TDD で修正する

関連

• フィードバック discussion: 【修正済み】2026/05/30 14:44 [不具合報告] ルビー内に表示されているプログラムがコード内で消えている smalruby3-develop#91

[takaokouji]

再現確認の結果 (2026-06-04): 本番環境 + headful Chrome でも再現せず

ホスト macOS の実 Chrome (headful) を Playwright MCP で操作する構成を整備し、実際に発生報告のあった本番環境 (https://smalruby.app) に対して再現確認を実施した。

試行したシナリオと結果

シナリオ	結果
issue 記載の仮説手順 (プログラム + コスチューム2枚 → ルビータブ → コード → コスチューム → 2枚目選択 → コード)	❌ 再現せず
同上をタブ切替の待ち時間 50ms〜1000ms で変動させて 7 サイクル (レース条件誘発狙い)	❌ 再現せず
ルビータブで実編集 (modified 状態) → コードタブへ遷移して変換	❌ 正常動作 (旧ブロック削除 → 新ブロック生成の経路を deleteBlock フックで確認)
コードタブで Cmd+Z 連打 (Ruby→ブロック変換直後の undo がワークスペースを巻き戻す仮説)	❌ 変化なし
メンテナによる手動フリー操作 (実マウスドラッグ・タブ切替等、監視フック有効状態)	❌ 再現せず

監視フックによる計測内容

• Blocks.deleteBlock の全呼び出しをスタックトレース付きで記録 (全ターゲット対象)
• 空 XML での workspaceUpdate 発火の検出
• 2 秒周期のウォッチドッグ: 「VM にブロックがあるのに描画 0 (DESYNC)」「VM ブロック数が突然 0 (VANISHED)」の検出

いずれのシナリオでも異常は記録されなかった。

結論と次のステップ

ローカルに加えて本番環境でも既知の仮説手順では再現しない。環境差ではなく、操作・状態の組み合わせに抜けている条件があると考えられる。

次のステップとして、コードタブ遷移時のフック処理について upstream (scratchfoundation/scratch-editor) と本プロジェクトの実装差分を洗い出し、コードレベルで怪しい箇所を列挙する。その後、作為的な摂動 (意図的な遅延挿入など) を加えた再現確認を行う。

[takaokouji]

調査結果 (2026-06-04): upstream 差分の精査と摂動実験による再現

コードタブ遷移時のフック処理を upstream と比較し、容疑箇所への作為的な摂動 (perturbation) 実験を行った。P2b 実験で報告症状と完全一致する状態を決定論的に再現できた。

前提の訂正: scratch-blocks バージョンは upstream と一致している

当初「Smalruby は scratch-blocks v2 (Blockly v12) を先行採用、upstream develop は v1」と仮定したが、これは古いローカル checkout (2026-02-22 時点、scratch-blocks 1.3.0) に基づく誤りだった。最新の upstream develop を確認した結果:

• upstream develop の scratch-blocks: 2.1.19
• Smalruby の scratch-blocks: 2.1.19 (完全一致)
• blocks.jsx の onWorkspaceUpdate も upstream とほぼ同一 (Events.disable() パターン、コメント文言まで一致)。Smalruby 固有差分は Ruby 変換ブロックの再配置処理のみ

実験 1 (P1): Blockly v12 のイベント非同期配送による race window

Blockly v12 ではワークスペースのイベント (delete 等) が FIRE_QUEUE 経由で非同期配送される。実測したところ:

• block.dispose() の同期完了時点では VM は未受信 (vmBlocks=3 のまま)
• 約 16ms (1 フレーム) 後に move + delete が VM に配送される

この窓の間にタブ切替を行う摂動実験 (P1b) では:

観測点	値
タブ切替時点の VM ブロック数	3 (delete はまだ queue 内)
切替後の VM ブロック数	0 (stale delete が配送されスクリプト全体消失)
切替後のルビータブ	プログラム全文が残存
コードタブ再訪問時	空

「ルビータブに残る / コードタブで消える」の非対称状態が成立することを確認。ただしこのメカニズムは upstream と共通の構造 (同一バージョン・同一コード) であり、Smalruby 固有ではない。トリガーには何らかの delete イベントが必要で、低速端末ではフレーム時間延伸により窓が拡大する。バックグラウンド化 (rAF 停止) でも queue が滞留する。

実験 2 (P2/P2b): Ruby→ブロック変換 apply の非トランザクション性【本命】

target-applier.js の applyTargetBlocks() は:

Object.keys(target.blocks._blocks).forEach(blockId => {
    target.blocks.deleteBlock(blockId);   // 1. 全削除が先
});
Object.keys(this._context.blocks).forEach(blockId => {
    target.blocks.createBlock(...);        // 2. ここで throw すると削除だけ残る
});

createBlock を特定 opcode で決定論的に throw させる摂動 (P2b) の結果:

観測点	値	意味
apply 実行回数	2	useEffect が変換を二重起動している (別の問題として要修正)
例外の行き先	unhandled rejection ×4	ruby-tab.jsx の .then() チェーンに .catch がなくエラー表示は一切出ない
VM ブロック	6 個 (hat なし)	hat の create だけ失敗 → 親チェーンが断裂した孤児ブロックが残る
コードタブ描画	0 個 (完全に空)	孤児グラフは XML に top-level スクリプトとして出力されない
ルビータブ	プログラム全文が残存	redux の rubyCode は独立保持

報告症状「ルビータブにはプログラムが残っているのに、コードタブのブロックだけが消える」と完全一致。

重要な点として、この経路は throw がなくても成立しうる: コンバーターが特定の Ruby 構文で親チェーンの壊れた blocks グラフを生成した場合、apply は「成功」しつつ描画は空になる。実際 blocks.jsx の既存コメント (forceRerender error guard) に、scratch-blocks v2 が特定の Ruby 変換スクリプト (a = [1,2,3]; a.each do |i| puts i end 等) で throw する実例が記録されている。

こちらは Smalruby 固有のコード (ruby-tab / target-applier) であり、症状の非対称性とも一致するため、本命の容疑と判断する。

修正の方向性 (案)

1. apply のトランザクション化 (最優先): 削除前に旧ブロック・コメントをスナップショットし、create 失敗時はロールバック。ruby-tab.jsx の変換チェーンに .catch を追加してエラーをアラート表示する
2. apply 後の整合性検証: 生成後に top-level スクリプトが存在するか (孤児グラフでないか) を検証し、異常なら旧状態に戻す — throw しないコンバーターバグにも有効
3. 変換の二重起動の解消: useEffect が同一タブ切替で apply を 2 回起動している問題の修正
4. (upstream 共通の問題として) stale イベント race は別 issue として切り出しを検討

再現環境メモ

• ホスト macOS の実 Chrome (headful) を Playwright MCP (HTTP server mode) で操作し、ローカル dev server に摂動を注入して検証
• 摂動はブラウザコンソール注入 (VM オブジェクトのメソッドフック) で実施。ソース変更なしで再現可能

[takaokouji]

PR #714 のマージで自動クローズされたが、再オープンする。

PR #714 は「Ruby→ブロック変換 apply の失敗でブロックが消える」経路への防御的修正であり、これ自体は価値があるが、実際に報告されている発生はルビータブへの遷移を伴わないとのこと。そのため、調査で確認したもう一方のメカニズム — Blockly v12 (scratch-blocks v2) の FIRE_QUEUE 非同期イベント配送による stale イベント race（イベント生成から VM 配送まで約 16ms = 1 フレームの遅延窓があり、低速端末ではさらに拡大。queue 内の delete イベントがタブ切替やワークスペースリロードを跨いで配送されると、トップブロックの delete 1 件でスクリプト全体が VM から消える）— が本命の容疑として残る。

この race は最新 upstream develop と共通の構造（scratch-blocks 2.1.19・onWorkspaceUpdate の Events.disable() パターンともに一致）であることを確認済み。

次のステップ: stale イベント race への対策を本 issue で継続する。

[takaokouji]

根本原因の特定 (2026-06-05): moveBlock の top-level shadow ガード欠落

実際の発生条件が「コスチュームタブでコスチューム追加 → コードタブ遷移(削除操作なし・ルビータブ不使用)」であるとの情報を受け、「upstream には問題がない」前提で本プロジェクトの変更箇所に絞って調査した結果、根本原因を特定した。修正: PR #717

原因

upstream のリリース済み修正 ae67b9bf（"fix bug that could result in the VM's representation of shadow blocks getting into a bad state"、scratch-editor v14.1.0 収録）の 2 hunk が、spork ロールバック時の blocks.js 復元 (84f87e9152, 2026-03-11) で削除され、scratch-blocks v2 (2.1.19) 再移行後も未復元のままだった。

欠落していたガード:

// upstream v14.1.0 (正)
if (typeof e.newParent === 'undefined') {
    if (!this._blocks[e.id].shadow) {   // ← このガードが欠落していた
        this._addScript(e.id);
    }
}

メカニズム (摂動実験で再現・確認済み)

1. shadow ブロックの「親なし move イベント」1 件で shadow が _scripts に混入
2. toXML() がトップレベル <shadow> 要素を出力
3. ワークスペースリロード時に scratch-blocks v2 が Shadow block cannot be a top-level block を throw — clear 済みのため shadow 要素以降のスクリプトがすべて描画されない
4. VM データは無傷 → スクリプトは動き続け、ルビータブにはプログラムが表示される

間欠性の説明 (実測)

_scripts 内の shadow の位置	症状
末尾	見た目は正常 = 潜伏状態（throw は手前のスクリプトロード後に発生し握りつぶされる）
先頭側	後続スクリプトが全滅（全消失）

潜伏状態で気付かないまま使い続け、任意のタブ遷移（コスチューム→コード等）のリロードで顕在化する。発生時はコンソールに Workspace Update Error: Failed to load workspace XML (Shadow block cannot be a top-level block.) が出る（再発報告があった場合はこのログの有無が決め手になる）。

これは upstream の High Severity issue scratch-blocks#3543「Invisible blocks」と同一の症状クラス。upstream は SB3 round-trip のサニタイズ（取り込み済み）+ moveBlock ガード（今回復元）の両方で対策していた。

これまでの 3 対策との関係

• fix: make Ruby-to-blocks apply transactional to prevent block loss (#710) #714（apply トランザクション化）・refactor: make RubyTab the single owner of the leave-Ruby-tab conversion (#710) #716（変換一本化）: ルビータブ経路の別問題への有効な防御（今回の発生条件とは独立）
• fix: drop stale block delete events delivered after a workspace reload (#710) #715（stale delete ガード）: Blockly v12 非同期配送の race への防御（同上）
• fix: restore upstream guard against top-level shadow blocks in moveBlock (#710) #717（本修正）: コスチューム→コード遷移での消失を直接説明する根本原因

既存の潜伏状態の治癒

_scripts に shadow が混入済みのプロジェクトも、保存/読込時に sb3 の両方向サニタイズ（upstream から取り込み済み）で治癒する。