Firefox is sometimes unable to load/render previously cached images (avatars)

We are investigating what seems to be a Firefox bug relating to avatars being cached on disk and then retrieved by a later request.

Reported to Firefox as:

The way this problem manifests is missing avatars where one would normally be present, e.g.:

These are respectively:

<img loading="lazy" alt="" width="24" height="24" src="https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/mancera1979/48/732001_2.png" class="avatar" title="mancera1979 - Frequent Poster">
<img loading="lazy" alt="" width="24" height="24" src="https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/jca34f/48/340148_2.png" class="avatar" title="JCA34F - Frequent Poster">

and those URLs redirect to, respectively:

https://europe1.discourse-cdn.com/arduino/optimized/4X/3/3/7/337a5e4169461364c9805cfad882c9eb0332bdf3_2_48x48.png
https://europe1.discourse-cdn.com/arduino/optimized/4X/4/b/8/4b8c803f304aa7e7c487184224ec9f970c96e8c4_2_48x48.jpeg

While inspecting the DOM using the devtools, Firefox reports “Could not load the image”

It’s never on initial requests that this fails - it’s always only happened on subsequent requests that would load the image from cache:

Reloading the page sometimes triggers Firefox to load the image properly, e.g.:

after a reload:


We know that:

… the problem is not specific to the Discourse application itself. We have reproduced the problem with a static HTML page containing only links to avatars:

image

image

… disabling http3 in Firefox does not resolve the problem

… flushing the browser cache causes the images to properly load the next time

… end users have reported this problem on desktop and mobile

We suspect that:

… this has something to do with the image being loaded after a redirect

Certain of our hosting environments have a “redirect chaser” installed that causes a request to the the original URL to return the image itself instead of a redirect to the image. I do not believe anyone has experienced this problem in those environments.

We do not have:

a start-to-finish consistent & clear reproduction of the problem

6 Likes

I’ve seen this myself on Firefox. Don’t know if it’s relevant at all but my site uses bunny.net as a cdn

1 Like

Interesting. OK, if you have any further details or reproduction steps, feel free to post them here.


:face_with_raised_eyebrow:
:microscope:

Well, that is EXCEEDINGLY appropriate :laughing:

4 Likes

This to me feels like our next port of call @david , a site setting that disables this to see if it has any impact.

1 Like

Since @supermathie has a vague repro on a static page, perhaps we try creating a version of that without loading="lazy"? Much easier than modifying Discourse to do it.

Is that something you could try @supermathie?

2 Likes

I wouldn’t use any other CDN! :rabbit2:

1 Like

I’ve been reloading them off and on, and just now replicated the problem by loading the lazy page (worked) then the non-lazy page (failed):

Unfortunately, Firefox seemed to completely reload assets on reload (Disable Cache is not set) with devtools open, but… this is odd:

The user seems to have changed/updated their avatar, and we redirected to the new one? I’m not sure what triggers this @david.

I’d hazard a guess this additional redirect briefly triggered the Firefox bug. Which is in line with the difference in behaviour due to the redirect chaser.

Maybe I can trigger it?

I changed my avatar, let’s see if it breaks when I reload in an hour.

EDIT: eh, it didn’t break this time

but my shenanigans on this page seem to be poorly affecting other pages… NONE of these avatars are working now and I think it’s because a network request is “stuck”.

2 Likes

Today: I reloaded the page with lazy, and it loaded fine:

image

I then loaded the page without lazy, and:

image

:person_shrugging:

So I guess that means it’s unlikely lazy= is the cause of the issue? At least that’s one thing ruled out :sweat_smile:

2 Likes