1937723 - www.zittauer-schmalspurbahn.de - The site does not update when refreshing the page

Status: NEW

(Web Compatibility :: Site Reports, defect, P3)

Description

[Raul Bucata]

Environment:
Operating system: Windows 10
Firefox version: ALL Versions later / after Firefox 99.0

Steps to reproduce:

1. Navigate to: https://www.zittauer-schmalspurbahn.de/webcam/picbertsdorf/Still/073003_SNCPeriodic.jpg
2. Refresh the page
3. Wait for a minute or two
4. Refresh the page again and observe the time stamp

Expected Behavior:
The picture is updated every minute

Actual Behavior:
The picture does not update

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/145287

Comment 1

[BugBot [:suhaib / :marco]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 2

[James Graham [:jgraham]]

We're seeing max-age=2592000 on the response, so it seems reasonable that we're caching it, but we didn't spot any significant differences compared to the response headers that Chrome gets, so more diagnosis is needed.

Comment 3

[Sunil Mayya]

Attachment: DevToolsAndWindow.png

The image in devtools and image rendered on the window are different.
The image shown in devtools seems to contain the latest timestamp.
We certainly seem to have a bug here.
I will check this further.

Comment 4

[Valentin Gosu [:valentin]]

I think this is an issue with the image cache.
As Sunil mentioned, looking at devtools, you can see that a new image was loaded from the network and stored in the cache.
In fact, opening the same URL in a new tab will show the updated image.
I expect the problem here is either that the new image doesn't reach the content process, or more likely that there's a problem updating the image cache.

Jeff, could you have a look?

Comment 5

[AutoWebCompat]

Attachment: Reproduction script generated by autowebcompat bot

The webcam still image at www.zittauer-schmalspurbahn.de is served as a top-level JPEG document that the camera overwrites about every 30 seconds, with cache-control: max-age=2592000. In Firefox, reloading the page keeps rendering the original picture, so the webcam view stays frozen at the image loaded first. Chrome renders the newly published picture on every reload.

Comment 6

[AutoWebCompat]

Root cause analysis generated by autowebcompat bot:

Engine difference, not site/UA sniffing — the site is a bare JPEG served as a top-level image document with Cache-Control: max-age=2592000, overwritten server-side every ~30 s at the same URL.

Firefox paints image documents (and images generally) out of its global, URL-keyed decoded-image cache (imglib / the HTML "list of available images"), and that cache entry is neither invalidated nor bypassed when newer bytes for the same URL are actually fetched from the network. On a normal reload of the image document Gecko does re-issue the navigation request and does receive the newer JPEG (fresh 200, newer Last-Modified, different Content-Length), but the <img> that the image document synthesises resolves against the still-"fresh" (max-age=2592000) imglib entry, so the newly downloaded bytes are discarded and the first-loaded picture keeps being painted. Chrome renders the bytes delivered by the reload's navigation response, so the new picture appears.

Relevant spec text: a media/image document is supposed to display the resource that the navigation already fetched (https://html.spec.whatwg.org/multipage/document-lifecycle.html#read-media), and reload navigations use Fetch cache mode "reload"/"no-cache" (https://fetch.spec.whatwg.org/#concept-request-cache-mode), which must not be short-circuited by the higher-layer image cache ("list of available images" / "ignore higher-layer caching": https://html.spec.whatwg.org/multipage/images.html#list-of-available-images and https://html.spec.whatwg.org/multipage/images.html#update-the-image-data). Firefox's URL-keyed image cache wins over both, which is the divergence.

Evidence:

Live site, both browsers driven via DevTools, pixel-hash of document.images[0] drawn into a canvas (same-origin image document, so readable):

• Initial load: FF hash 3997324393, Chrome hash 3997324393 (same picture, server Last-Modified 16:55:34).
• Waited until a cache-busted HEAD showed Last-Modified change 16:55:34 → 16:56:04, then reloaded both tabs.
• After reload: Chrome hash 377460527 (new picture), Firefox hash still 3997324393 (frozen).
• Firefox network log for that reload: GET …073003_SNCPeriodic.jpg, 200, last-modified: Thu, 03 Sep 2026 16:56:04, content-length: 67155 (initial load was 67388 / 16:55:34). So Firefox downloaded the NEW bytes in that very load and still painted the OLD picture ⇒ not the HTTP cache, but the image cache.
• Extra: in Firefox even navigating away (file:// page) and back to the URL still painted the original 16:55:34 picture minutes later; a subresource <img> reload behaves the same in both browsers (both stale), so the divergence is specific to the image-document main-resource path.

Reduced testcase /app/diagnosis/testcase=l738p8o0.html (file://, run in both): loads the webcam URL, waits 70 s, does fetch(url, {mode:'no-cors', cache:'reload'}) — Firefox network log confirms this went to the network and returned the newer picture (last-modified 17:03:34, 61294 bytes) — then location.reload() and shows the plain URL next to a cache-busted control.

• Chrome: both images show burned-in timestamp 19:07:35 (identical) → the freshly fetched bytes are painted. PASS.
• Firefox: plain-URL image shows 18:57:35 while the control shows 19:07:35 → Firefox painted an image-cache entry that is older even than the bytes sitting in its own HTTP cache, with no network request for that <img>. FAIL. Same divergence as the site.

Comment 7

[AutoWebCompat]

Attachment: Reduced testcase generated by autowebcompat bot