mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-14 14:23:14 -06:00
a1aeb324d7
sw.js said its cache-first widget branch "is what lets a widget keep rendering when the network is gone". It is not. The player mounts widgets in an iframe sandboxed to `allow-scripts` with no allow-same-origin, so the frame is an opaque-origin client, and a service worker does not control those — the navigation never reaches the handler. Measured rather than reasoned: a clock widget mounted five times over 25 seconds of real playback in Chrome while the shell cache held zero widget entries, and a plain fetch() of the identical URL from the controlled page was intercepted and stored on the first try. The branch works; the player's own widgets are simply not what reaches it. What actually holds widgets through an outage today is the HTTP cache plus the server's `max-age=31536000, immutable` on a rev-pinned render. That is sound in a desktop browser and is exactly the store this module's own header says is NOT persistent on BrightSign, which is why content caching had to exist at all. So the comment now records the limit and names the two ways out — route the render through a same-origin fetch and mount it as srcdoc, or grant allow-same-origin and hand widget scripts the player's origin, which is not a trade worth making for an offline nicety. The test pins the security property so nobody buys the cache with it, and pins the Cache-Control header, which is now known to be load-bearing on its own. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL |
||
|---|---|---|
| .. | ||
| debug-overlay.js | ||
| index.html | ||
| sw.js | ||