Safari stopped showing avatars

On observablehq.com, Safari stopped showing avatars, instead showing a grey filled circle. Firefox and Chrome work fine.

I’ve removed all cookies and all history, restarted Safari several times, restarted my Mac. Problem persists.

Any clues?

Safari Version 16.4.1
MacOS 12.6.5

I see user Avatars on my profile page with Safari. My Mac OS is up to date but my Safari version is woefully out of date, as I rarely use it. It does sound like a weird cache related issue, though.

Could you try viewing it in incognito mode and see if that works?

Same symptoms. That is, same grey filled avatars.

Also tried, to no avail:

  • Developer > Empty Caches
  • Developer > Disable Images, Enable Images

Do you see any messages in the DevTools console or any failing network requests?

Console shows no errors.
Sources > Images do show the avatars, though.

Do get two identical URLs, but with different parameters:

I do see references like: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAAAAAA6fptVAAAACklEQVR4nGOaCQAAnwCc1NtUdAAAAABJRU5ErkJggg==

Should show as mbostock’s avatar, yet doesn’t.

Identical symptoms if I switch to another user on same Mac.

Now I am suspicious about Safari 16.4.1.

I am on 16.4 and MacOS 13.3.1 and things look correct on mine.

Tried to revert to 16.4 from Time Machine, but macOS does not allow me to.

(Cannot use macOS 13 or later because of late 2015 iMac.)

Hi @Cobus,

Revisiting this, because I hoped Safari Version 16.5 (17615.2.9.11.6, 17615) (just released) would fix this, but no.

When opening https://observablehq.com/@mbostock?tab=notebooks, I see:

Inspecting the elements,

  • Safari uses: <img alt="@mbostock" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAAAAAA6fptVAAAACklEQVR4nGOaCQAAnwCc1NtUdAAAAABJRU5ErkJggg==" class="br-100 mr1 nt1 nb1" style="width: 16px; height: 16px; max-width: none; flex-shrink: 0; display: block;">
  • Chrome and Firefox use: <img alt="@mbostock" src="https://avatars.observableusercontent.com/avatar/82811927da99f8938001b2ef1f552ad2c47083e46ebc55a3a146a5a5848c4519?s=60" style="width: 16px; height: 16px; max-width: none; flex-shrink: 0; display: block;" class="br-100 mr1 nt1 nb1">

So if I understand correctly, Safari gets fed Data URLs, a base64 encoded image/png.

When I decode the data like so:

echo -n 'iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAAAAAA6fptVAAAACklEQVR4nGOaCQAAnwCc1NtUdAAAAABJRU5ErkJggg==' | base64 -D > mbostock

I get:

file mbostock
mbostock: PNG image data, 1 x 1, 8-bit grayscale, non-interlaced

So, where is the decision made to use data: over https:? I guess it’s Observable.

Also, why is the resulting image a 1x1 8-bit grayscale instead of a JPEG image data, baseline, precision 8, 60x60, components 3?

Curious about any clues.

Thanks in advance.

The data URL is a placeholder image that gets set when there’s an error while loading the image.

Unless someone else reports the same problem I doubt that there’s anything we can do about it. Do you have any Safari extensions enabled?

I do have Bear Writer extension active, as well as a mymind extension since last week.

However, turning them off has no effect on these symptoms, not even after restarting Safari.

You say,

The data URL is a placeholder image that gets set when there’s an error while loading the image.

Does this mean that it can be a network problem (latency and/or bandwidth)?

ALso, who sets this placeholder image, and can I see the loading error somewhere? Safari’s console show no such loading errors/stays clean.

The placeholder image is set by the application.

I suspect this might be a certificate issue for the domain avatars.observableusercontent.com (i.e., Safari uses a stale certificate). The current certificate was issued on March 10, 2023, and the old one may have expired when you started noticing those problems.

Are you able to open the any of the avatar images directly in Safari, without warnings? And can you try connecting via a VPN?

This is my certificate:

That is, Observable? Or the browser?

Yes, I am. Safari, Chrome and Firefox all open https://avatars.observableusercontent.com/avatar/82811927da99f8938001b2ef1f552ad2c47083e46ebc55a3a146a5a5848c4519 without any problem.

VPN right now is difficult, as I have none set up.

Yes, Observable.

No problem, won’t be necessary anymore.

Does that also apply to the avif variant? Can you open that as well in Safari without problems? https://avatars.observableusercontent.com/avatar/40dc8e4f86d0cf89184b173b4d1d88336e5728c175479f33261ced3496adb3c2?s=120&format=avif

Opening works fine in all three browsers.

In that case I’m out of ideas. Best advice I can give is to browse the site in Safari with your dev tools network tab open, the cache disabled, console visible, and watch if you see any errors pop up.

Okay.

New information: I opened the network tab, and see the list of avatar names. Two entries with same name, but different URLs:

First one works as expected:

URL:

https://avatars.observableusercontent.com/avatar/82811927da99f8938001b2ef1f552ad2c47083e46ebc55a3a146a5a5848c4519?s=60

Second one fails in Safari, yet succeeds in Chrome and FF:

URL:

https://avatars.observableusercontent.com/avatar/82811927da99f8938001b2ef1f552ad2c47083e46ebc55a3a146a5a5848c4519?s=120&format=avif

Headers, Cookies, Sizes, Timing, Security tabs in Network tab all look good, except for Preview tab (see above).

At this point you’d probably have to open up macOS’ Console application, start logging and then watch what gets reported when you try to preview the avif resource. If you want to go down that road be ready to sift through lots of noise.

Perhaps you’re encountering this WebKit bug: 256119 – REGRESSION(259684@main-259698@main?) [[ Ventura wk2 ] fast/images/avif-as-image.html is a constant ImageOnlyFailure

I’m not sure how far ahead nightly builds are of regular releases, but looking at the (unmerged) fix, the bug seems like a good fit: REGRESSION(259684@main-259698@main?) [[ Ventura wk2 ] fast/images/avif-as-image.html is a constant ImageOnlyFailure by litherum · Pull Request #14562 · WebKit/WebKit · GitHub (edit: I guess it got reported for nightly because it was reproduced on that version)