Page MenuHomePhabricator

TIF image fails to load after clicking on thumbnail
Closed, ResolvedPublic3 Estimated Story PointsBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

What happens?:
I get taken to https://en.wikipedia.org/wiki/Marman_clamp#/media/File:Typical_Marman_Clamp_System.tif. I can see an image flash briefly on the screen then replaced by a "broken image" icon. In the browser dev tools network tab, I can see a successful load of

https://upload.wikimedia.org/wikipedia/commons/thumb/4/41/Typical_Marman_Clamp_System.tif/lossy-page1-500px-Typical_Marman_Clamp_System.tif.jpg

immediately followed by an attempt to load

https://upload.wikimedia.org/wikipedia/commons/thumb/4/41/Typical_Marman_Clamp_System.tif/lossy-page1-708px-Typical_Marman_Clamp_System.tif.jpg

which fails with a 400 (Bad Request).

Request headers:

:authority
upload.wikimedia.org
:method
GET
:path
/wikipedia/commons/thumb/4/41/Typical_Marman_Clamp_System.tif/lossy-page1-708px-Typical_Marman_Clamp_System.tif.jpg
:scheme
https
accept
image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
accept-encoding
gzip, deflate, br, zstd
accept-language
en-US,en;q=0.9
cache-control
no-cache
cookie
WMF-Uniq=<a bunch of hex>
dnt
1
pragma
no-cache
priority
i
referer
https://en.wikipedia.org/
sec-ch-ua
"Google Chrome";v="149", "Chromium";v="149", "Not)A;Brand";v="24"
sec-ch-ua-mobile
?0
sec-ch-ua-platform
"macOS"
sec-fetch-dest
image
sec-fetch-mode
no-cors
sec-fetch-site
cross-site
sec-fetch-storage-access
active
user-agent
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36

Response headers:

access-control-allow-origin
*
access-control-expose-headers
Age, Date, Content-Length, Content-Range, X-Content-Duration, X-Cache
content-length
2035
content-type
text/html; charset=utf-8
date
Tue, 16 Jun 2026 11:55:49 GMT
nel
{ "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0}
report-to
{ "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }
server
Varnish
server-timing
cache;desc="int-front", host;desc="cp1113"
strict-transport-security
max-age=106384710; includeSubDomains; preload
timing-allow-origin
*
x-cache
cp1113 int
x-cache-status
int-front
x-client-ip
<IP v6 address elided>
x-request-id
e07500e5-6416-4531-9ad4-2860a4de2353

This is not entirely reproducible. For a while I was able to repro this in an incognito window, but I can no longer do so. The above headers are from a normal logged-in session.

What should have happened instead?:

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):
MacOS Monterey
Chrome Version 149.0.7827.103 (Official Build) (x86_64)

Event Timeline

Aklapper added a subscriber: Ladsgroup.

Thanks for taking the time to report this!

Per T428223 and T428202 I would have expected this to be fixed last week, but I can reproduce.

Those tickets were about webp files. The problem is the file is 708px and the open media viewer tries to open it with 960px which is bigger than the original, it can't show the original since it's tiff (unlike webp files) so it falls back to the original size thumbnail. It's not too easy to fix but also somewhat rare to happen.

SherryYang-WMF moved this task from Needs Refinement to Backlog on the Reader Growth Team board.

tiff is special in that it's an image format that chrome refuses to support. I wonder if this was always broken but just more visible with the new sizes, or if we recently broke it when we rewrote some of the loading code for MMV

tiff is special in that it's an image format that chrome refuses to support. I wonder if this was always broken but just more visible with the new sizes, or if we recently broke it when we rewrote some of the loading code for MMV

I'm 90% sure it's because of the refactors. We have been issuing 4xx for non-standard thumbs for a while now but these reports are quite more recent and many at once.

Krinkle claimed this task.
Krinkle added subscribers: simon04, Krinkle.

As part of the work by @simon04 and myself under T426246 and T77391, we now fetch the thumbnails from the imageinfo API, which avoids this problem.