Page MenuHomePhabricator

File:Chessboard480.svg WEBP thumbnail version not visible on safari when size is fixed at 208px
Closed, ResolvedPublic

Description

So I came across this weird issue on itwiki, and several other users confirmed it. On itwp we use File:Chessboard480.svg for chess diagrams. The template we use will set a fixed dimension of 208 px for the image, thus producing the following wikitext:

[[File:Chessboard480.svg|208px]]

For some reason, this doesn't show up on safari (iOS or Mac). Instead, an empty square box is shown with a link to the image at the top (I might upload a screenshot later). You can verify the issue yourself by visiting this page: the first image is the broken one; the second one doesn't specify a fixed size and is shown on safari as expected.

The other weird thing is that issue seems to be image-specific and size-specific. That is, if I use another SVG file, it works (example), and if I change the original size from 208px to something else, e.g. 209px, it also works (example). Additionally, this issue doesn't happen 100% of the times. Sperimentally, it seems to be broken roughly 90-95% of the times.

My first guess would be a caching issue, but then I can't explain why it's safari-only. I'm not even sure what the appropriate tags might be here. Tentatively tagging SRE in case this turns out to be an issue with the caching layer.

Event Timeline

Daimona claimed this task.

Regenerating the thumbnail (via this link) fixed it.

Daimona removed Daimona as the assignee of this task.

Actually, it's still broken. It did work immediately after regenerating the thumbnail, but now it's broken again.

Is this just safari on iOS and Mac? This works for me (at least on 1 try) on:

  • Google Chrome logged in user on Linux
  • Google Chrome logged out and incognito mode on Linux
  • Firefox logged out on Linux
  • Firefox incognito and logged out on Linux.

I can't off hand think a valid reason to just target Safari (logged in or not btw? Also does incognito mode play any role?) on the caching layer. I think we need some more information to figure out what's going on there. Perhaps a developer tools output[1] while reproducing that? The response specifically would be very useful.

[1] https://support.apple.com/guide/safari-developer/network-tab-dev1f3525e58/mac

Triaging as low until we can have an easy reproduction scenario.

Is this just safari on iOS and Mac? This works for me (at least on 1 try) on:

Yes, apparently. I and two other users who experience this issue are all using safari, either iOS or MacOS. Other browsers work just fine, at least for me. Logged in vs logged out (incognito mode) doesn't make any difference, for me at least.

I can't off hand think a valid reason to just target Safari (logged in or not btw? Also does incognito mode play any role?) on the caching layer.

+1.

I think we need some more information to figure out what's going on there. Perhaps a developer tools output[1] while reproducing that? The response specifically would be very useful.

[1] https://support.apple.com/guide/safari-developer/network-tab-dev1f3525e58/mac

I managed to get some data on a Mac. Here are the results for the broken picture on the current version of my sandbox. I've manually translated the output, so it might be a bit different from what you'd actually see on a Mac.

URL: https://upload.wikimedia.org/wikipedia/commons/thumb/d/d7/Chessboard480.svg/208px-Chessboard480.svg.png
Source: Network

Request
:method: GET
:scheme: https
:authority: upload.wikimedia.org
:path: /wikipedia/commons/thumb/d/d7/Chessboard480.svg/208px-Chessboard480.svg.png
Accept: image/webp,image/png,image/svg+xml,image/*;q=0.8,video/*;q=0.8,*/*;q=0.5
Accept-Encoding: gzip, deflate, br
Host: upload.wikimedia.org
Connection: keep-alive

Response
:status: 200
Timing-Allow-Origin: *
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Server-Timing: cache;desc="hit-front", host;desc="cp3059"
Content-Disposition: inline;filename*=UTF-8''Chessboard480.svg.webp
Content-Length: 100
Date: Wed, 21 Apr 2021 10:04:42 GMT
Access-Control-Expose-Headers: Age, Date, Content-Length, Content-Range, X-Content-Duration, X-Cache
Age: 4443
Content-Type: image/webp
Last-Modified: Sun, 18 Apr 2021 11:09:30 GMT
Server: ATS/8.0.8
Strict-Transport-Security: max-age=106384710; includeSubDomains; preload
x-cache-status: hit-front
x-cache: cp3061 hit, cp3059 hit/179

The working version was instead loaded from the local cache. I didn't try to empty that cache.

akosiaris added a subscriber: ema.

So a successful fetch per safari, of 100 bytes per Content-Length. Interestingly, my tests are almost identical HTTP headers wise. We share almost all headers, minus Date and a minor diff in x-cache (I got hit/213). And yet from what I understand the content is garbage/garbled or something similar. I am gonna add @ema and Traffic on this one. It brings back memories of T266373

Thanks for pointing me to this task @akosiaris. The issue here is webp, this is broken on Safari: https://upload.wikimedia.org/wikipedia/commons/thumb/d/d7/Chessboard480.svg/312px-Chessboard480.svg.png.webp

Here's how the file gets rendered on my iPhone:

IMG_0060.PNG (2×1 px, 382 KB)

Change 681685 had a related patch set uploaded (by Ema; author: Ema):

[operations/puppet@production] cache: do not serve webp files to Safari

https://gerrit.wikimedia.org/r/681685

Aklapper renamed this task from File:Chessboard480.svg not visible on safari when size is fixed at 208px to File:Chessboard480.svg WEBP thumbnail version not visible on safari when size is fixed at 208px.Apr 21 2021, 7:09 PM

This started happening because Safari 14 is supposed to support WebP (and serves relevant Accept headers), but their WebP decoding is clearly buggy as demonstrated here.

Change 681685 merged by Ema:

[operations/puppet@production] cache: do not serve webp files to Safari

https://gerrit.wikimedia.org/r/681685

@ema I've just realised that the net was too wide. Chrome has "Safari" in its UA string, for example:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36

An example for actual Safari 14:

Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15

So we probably want to grep for "Safari/6"

Change 682672 had a related patch set uploaded (by Ema; author: Ema):

[operations/puppet@production] cache: Safari regex refinement

https://gerrit.wikimedia.org/r/682672

Change 682672 merged by Ema:

[operations/puppet@production] cache: Safari regex refinement

https://gerrit.wikimedia.org/r/682672

Daimona assigned this task to ema.

Working as expected now, thank you!