⚓ T375981 Preferences settings for small image size are not being respected for Parsoid Read Views
Page Menu
Phabricator
Create Task
Maniphest
T375981
Preferences settings for small image size are not being respected for Parsoid Read Views
Closed, Resolved
Public
BUG REPORT
Actions
Edit Task
Edit Related Tasks...
Create Subtask
Edit Parent Tasks
Edit Subtasks
Merge Duplicates In
Close As Duplicate
Edit Related Objects...
Edit Commits
Edit Mocks
Mute Notifications
Protect as security issue
Assigned To
MSantos
Authored By
WhatamIdoing
Sep 29 2024, 6:23 PM
2024-09-29 18:23:25 (UTC+0)
Tags
Parsoid
(Missing Functionality)
Parsoid-Read-Views (Small Size Wikipedias)
(Backlog)
Content-Transform-Team (Work In Progress)
(To Verify)
OKR-Work
(Backlog)
Readers Essential Work (WE6.3.4 Fix bugs within the reading experience across platforms for Parsoid Read Views)
(Thumbnail simplification)
Patch-For-Review
MW-1.46-notes (1.46.0-wmf.20; 2026-03-17)
Referenced Files
None
Subscribers
Aklapper
Arlolra
cscott
Daimona
DerFussi
Izno
Jdlrobson
View All 19 Subscribers
Description
Steps to replicate the issue
See
The replication steps are:
Visit
Set thumbnail size to 400px (the default is 250px)
Compare
with
What happens?
The image is bigger in the legacy parser.
What should have happened instead?
The image should be the same, or we should drop support for this thumbnail preference as part of the roll out of parsoid
Other information
(browser name/version, screenshots, etc.):
We vary the HTML based on the thumbnail setting
For 400px we serve a 500px image and scale it down using width and height attributes on the element in legacy parser
The default is 250px
Impacts all read views on projects where Parsoid is default (e.g. Wikivoyage)
Details
Related Changes in Gerrit:
Subject
Repo
Branch
Lines +/-
Skins: Address issue with blurry images for large thumbnails
mediawiki/core
wmf/1.46.0-wmf.20
+41
-18
Skins: Address issue with blurry images for large thumbnails
mediawiki/core
master
+41
-18
Support CSS/JS thumbnail sizing in Parsoid
mediawiki/core
master
+171
-4
Fix CSS/JS thumbnail sizing in Parsoid: don't upscale small images
mediawiki/core
master
+3
-1
Customize query in gerrit
Related Objects
Search...
Task Graph
Mentions
Duplicates
Status
Subtype
Assigned
Task
Open
None
T378089
[EPIC] Wikivoyages rollout followup work
Resolved
BUG REPORT
MSantos
T375981
Preferences settings for small image size are not being respected for Parsoid Read Views
Open
None
T376152
Evaluate feasibility of deprecating (or limiting) user media size preferences
Open
None
T417514
Remove `thumbsize` from ParserOptions
Declined
MSantos
T417515
Parsoid should include 4x image size in srcset to accomodate large thumbsize preferences
Resolved
MSantos
T417516
Thumbnail sizes should be configurable
Mentioned In
T423676: Infobox images have huge padding in Firefox
T417828: Some images become disproportionately big in 1.46.0-wmf.16
T417516: Thumbnail sizes should be configurable
T417515: Parsoid should include 4x image size in srcset to accomodate large thumbsize preferences
T417514: Remove `thumbsize` from ParserOptions
T417513: Switch to CSS/JS solution for thumbnail size in legacy parser
T414852: Run a survey to understand why existing logged in users might be opting out of Parsoid
T392189: Default thumbnail size does not change image size on the page
T373966: Parsoid ignores user-set image size
Mentioned Here
T417513: Switch to CSS/JS solution for thumbnail size in legacy parser
T420657: Preferences settings for small image size are not compatible with upright for Parsoid Read Views
T419927: PNGs are being displayed at a too-low, blurry resolution
T351: RfC: Square bounding boxes
T9003: Allowthumbnail size of an image to be defined as proportion of the user's default
T37756: Image parameter for thumbs that scale to an exact box, cropping as necessary
T65903: Thumbnails should use a square bounding box by default
T65904: The 'upright' option should use a square bounding box
T417828: Some images become disproportionately big in 1.46.0-wmf.16
T406724: Clean up watchlist and user properties of users if they don't log in for certain time
T402792: Consider rate limiting non-standard thumbnail sizes
T148047: Desktop MediaWiki should be able to lazy load images
T106640: Choose a sensible set of thumbnail sizes for Special:Preferences
T360589: De-fragment thumbnail sizes in mediawiki
Duplicates Merged Here
T417828: Some images become disproportionately big in 1.46.0-wmf.16
T411414: Parsoid doesn't respect file thumbnail size setting
T373966: Parsoid ignores user-set image size
Event Timeline
There are a very large number of changes, so older changes are hidden.
Show Older Changes
Ladsgroup
added a comment.
Dec 2 2025, 2:03 PM
2025-12-02 14:03:15 (UTC+0)
Comment Actions
In
T375981#11423752
@Ladsgroup
wrote:
So in terms of the load on the infra, this is not an issue anymore since mediawiki automatically turns them into one of the steps (
T360589
) so this is merely a css config at this point.
But there is a complexity here, The default is 250px. For users who use below that, we can simply do css. But for larger ones, mediawiki currently is loading 330px (the next larger standard size) and then scale down. So if we fully remove the part and let css take over, the images will become blurry for those users since mw will load 250px.
Mr._Starfleet_Command
added a comment.
Dec 2 2025, 3:27 PM
2025-12-02 15:27:23 (UTC+0)
Comment Actions
IMO, the parser should give the same output regardless of user preference, so if we keep this preference, it should be done via CSS. As Ladsgroup mentioned, this would result in users who set their preference above 250px getting blurry images. I can think of two possible solutions:
Remove all options greater than 250px.
Have the parser serve a larger thumbnail for everyone and scale it to 250px for logged-out users and those who keep the default preference.
Not sure which of those is best, or if it might be better to remove the user preference entirely, but those are the three best options so far as I can see.
Ladsgroup
added a comment.
Edited
Dec 2 2025, 3:54 PM
2025-12-02 15:54:11 (UTC+0)
Comment Actions
One thing that could be a middle ground is to have "large thumbnail" mode and split the PC into two modes, default and large. Then all other options would simply turn into a css. PC would split into two but better than six/seven. Loading everything with 500px for everyone is a non-starter. The increase would be quite big.
Jdlrobson-WMF
added a comment.
Dec 2 2025, 10:18 PM
2025-12-02 22:18:54 (UTC+0)
Comment Actions
Remove all options greater than 250px.
Yes. I think it would be sensible to remove these.
One thing that could be a middle ground is to have "large thumbnail" mode and split the PC into two modes, default and large. Then all other options would simply turn into a css. PC would split into two but better than six/seven.
I'd be curious to know what % of people are using the 300px and 400px size? Do we know?
Loading everything with 500px for everyone is a non-starter. The increase would be quite big.
What if we also introduced lazy loaded images on desktop (
T148047
) ? Would that change things? Or is the concern not with the serving of the asset but that generating a 500px is more computationally expensive than 250px?
Ladsgroup
added a comment.
Dec 3 2025, 6:03 AM
2025-12-03 06:03:35 (UTC+0)
Comment Actions
In
T375981#11426268
@Jdlrobson-WMF
wrote:
Remove all options greater than 250px.
Yes. I think it would be sensible to remove these.
One thing is that this could be an accessibility vehicle. I have seen people needing to use magnifier tool so they can see text. A bigger image size definitely will help them. Don't know how many people use the large sizes for a11y reasons though.
One thing that could be a middle ground is to have "large thumbnail" mode and split the PC into two modes, default and large. Then all other options would simply turn into a css. PC would split into two but better than six/seven.
I'd be curious to know what % of people are using the 300px and 400px size? Do we know?
Yup, I linked the stats above. According to
T106640#10761152
it is 53K users using 400px and 59K users are using 330px
Loading everything with 500px for everyone is a non-starter. The increase would be quite big.
What if we also introduced lazy loaded images on desktop (
T148047
) ? Would that change things? Or is the concern not with the serving of the asset but that generating a 500px is more computationally expensive than 250px?
I don't think it'll change much but I need data before I can make an assessment in one way or another.
Jdlrobson-WMF
updated the task description.
(Show Details)
Dec 3 2025, 7:11 PM
2025-12-03 19:11:56 (UTC+0)
Jdlrobson-WMF
updated the task description.
(Show Details)
Dec 3 2025, 7:16 PM
2025-12-03 19:16:24 (UTC+0)
Mr._Starfleet_Command
updated the task description.
(Show Details)
Dec 3 2025, 7:20 PM
2025-12-03 19:20:46 (UTC+0)
Mr._Starfleet_Command
updated the task description.
(Show Details)
Dec 3 2025, 7:23 PM
2025-12-03 19:23:02 (UTC+0)
cscott
subscribed.
Dec 3 2025, 9:53 PM
2025-12-03 21:53:02 (UTC+0)
Comment Actions
I think having two thumbnail preferences ("normal" and "large/accessible") might solve most issues, although we'd still have the complexity in core of serving HTML with two different sizes. I haven't seen a discussion of responsive images yet: in many cases even though the screen px is fixed, our HTML mentions thumbnails in 3 or so different resolutions based on the screen magnification factor.
Ladsgroup
added a comment.
Edited
Dec 3 2025, 11:05 PM
2025-12-03 23:05:29 (UTC+0)
Comment Actions
In
T375981#11430509
@cscott
wrote:
I think having two thumbnail preferences ("normal" and "large/accessible") might solve most issues, although we'd still have the complexity in core of serving HTML with two different sizes. I haven't seen a discussion of responsive images yet: in many cases even though the screen px is fixed, our HTML mentions thumbnails in 3 or so different resolutions based on the screen magnification factor.
Oh that's actually a good idea. I don't know how hacky it would be on css side but we can theoretically change the 1x img src on large/a11y mode by taking it from 2x/1.5x and people who are using the large mode won't have responsive images (all img src values being the same). I think that's a good compromise but I don't know whether we'd have to resort to js hacks for this or not.
Jdlrobson-WMF
added a subscriber:
SherryYang-WMF
Dec 8 2025, 11:02 PM
2025-12-08 23:02:40 (UTC+0)
Jdlrobson-WMF
moved this task from
Backlog
to
Blockers
on the
Readers Essential Work (WE6.3.4 Fix bugs within the reading experience across platforms for Parsoid Read Views)
board.
Dec 8 2025, 11:19 PM
2025-12-08 23:19:55 (UTC+0)
MSantos
triaged this task as
Low
priority.
Jan 8 2026, 3:20 PM
2026-01-08 15:20:16 (UTC+0)
MSantos
moved this task from
Q4 FY25-26
to
Blocked
on the
Content-Transform-Team (Work In Progress)
board.
MSantos
subscribed.
Comment Actions
Moving this to blocked for now as we are pending a decision on the custom thumbnail sizes discussion.
MSantos
claimed this task.
Jan 12 2026, 4:28 PM
2026-01-12 16:28:45 (UTC+0)
gerritbot
added a comment.
Jan 16 2026, 1:23 AM
2026-01-16 01:23:57 (UTC+0)
Comment Actions
Change #1227492 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):
[mediawiki/core@master] POC: Serve a single source of HTML with two thumbnail options.
gerritbot
added a project:
Patch-For-Review
Jan 16 2026, 1:23 AM
2026-01-16 01:23:58 (UTC+0)
Jdlrobson-WMF
added a comment.
Edited
Jan 16 2026, 1:31 AM
2026-01-16 01:31:33 (UTC+0)
Comment Actions
@SherryYang-WMF
I chatted to Content Transform team about this today (
@MSantos
and
@cscott
). We'd like to find a middle ground where we add support to Parsoid for 2 different thumbnail options (as suggested in {
T375981#11424349
}. Ideally we'd have one, and scale it down but SRE have said "Loading everything with 500px for everyone is a non-starter" (
T375981#11424349
As part of this work we'd reduce the available preference options to two: standard and large. I'd need some help from Readers Growth with this end of Feb/early March. Bonus points if we could tie this to an A/B experiment relating to serving larger thumbnails by default to see how that impacts our key metrics.
It's in our interest to get Parsoid rolled out as it will mean cheaper experiments in readers growth and doing this proactively will reduce the likelihood of blockers. It also should help addressing urgent needs for de-risking WE4.3, WE5.4, and our infrastructure. I estimate a sprint of work (hopefully 5-8 points tops)
Currently
We have
8 variants of parser HTML
as we serve image width and height attributes for each option to support the option.
Thumbnail preference
Thumbnails requested (1x, 1.5x, 2x)
img width attribute
number of users with this preference in April 2025 (source:
T106640#10761152
120px
250px, 330px, 500px
120px
2.4K
150px
250px, 330px, 500px
150px
670
180px
250px, 330px, 500px
180px
1.7M
200px
250px, 330px, 500px
200px
5K
220px
250px, 330px, 500px
220px
380
250px (default)
250px, 500px
250px
N/A
300px
330px, 500px, 960px
300px
5.9K
400px
500px, 960px
400px
5.4K
Proposed
1 variant of parser HTML with 2 supported preferences.
Thumbnail preference
Thumbnails requested (1x, 1.5x, 2x, 4x)
img width attribute
estimated number of users
Previous preference values
Small (default)
250px, 330px, 500px, 960px
250px
N/A
120px,150px,180px,200px, 250px
Large
250px, 330px, 500px, 960px
250px (upgraded to 2x via CSS/JS)
112K
300px, 400px
This reduces the number of 330px queries; reduces preference table rows and reduces the parser cache variants from 8 to
one
provided we are okay with pixelated images until JavaScript kicks in and adding a 4x responsive query. We could serve the same HTML to everyone and add a class to the HTML element that controls the size. Proof of concept
patch
(patchdemo not working now but I can update later).
Note, we can use 2 variants if we are not okay with the above.
@Ladsgroup
would this be a sensible approach to pursue in just over a month from an SRE perpective?
Ladsgroup
added a comment.
Jan 16 2026, 1:11 PM
2026-01-16 13:11:03 (UTC+0)
Comment Actions
Hi, It would be nice to implement this but it's not really related to
T402792
as the served images all are in standard sizes.
Jdlrobson-WMF
mentioned this in
T414852: Run a survey to understand why existing logged in users might be opting out of Parsoid
Jan 16 2026, 11:08 PM
2026-01-16 23:08:31 (UTC+0)
cscott
moved this task from
Blocked
to
Q4 FY25-26
on the
Content-Transform-Team (Work In Progress)
board.
Jan 26 2026, 4:29 PM
2026-01-26 16:29:54 (UTC+0)
Jdlrobson-WMF
raised the priority of this task from
Low
to
Medium
Feb 4 2026, 8:54 PM
2026-02-04 20:54:16 (UTC+0)
OwenBlacker
subscribed.
Feb 5 2026, 7:22 AM
2026-02-05 07:22:24 (UTC+0)
Comment Actions
For what it's worth, I am one of the 53k users who has the pref set to 400px and in my case it is for accessibility.
I think I would probably be ok with the slight degradation of experience of blurry images until JS or CSS performs the upgrade (would that be onReadyStateComplete? It's a good while since I was doing much UI work myself)
I would worry, however, at the visual impact of the rendered images changing size and causing text reflow; that could be quite disorienting, itself an a11y issue (essentially violating my OS prefers-reduced-motion pref).
Am I worrying too much about a reflow event, given most pages have no default-sized images in the first screen-height? Or are infobox images also generally default-sized?
Mr._Starfleet_Command
added a comment.
Feb 5 2026, 2:31 PM
2026-02-05 14:31:37 (UTC+0)
Comment Actions
I'm no expert on this, but my guess is that CSS could scale the image to the right size from the start, even before the JavaScript changes the image source to a larger thumbnail. Thus there would be no text reflow. I could be wrong, though.
Jdlrobson-WMF
added a comment.
Feb 5 2026, 10:30 PM
2026-02-05 22:30:35 (UTC+0)
Comment Actions
@Mr._Starfleet_Command
yes that's correct!
@OwenBlacker
the proposed solution would not have a reflow and you would still get the same experience so no need to worry about a11y, it would just be JavaScript/CSS dependent now. It would also only effect images where no thumbnail size has been requested in the wikitext.
We can ship a solution for Parsoid first to allow editors to give us feedback before applying it to the legacy parser and all page views. Would that help alleviate concerns?
OwenBlacker
added a comment.
Feb 5 2026, 10:34 PM
2026-02-05 22:34:21 (UTC+0)
Comment Actions
@Mr._Starfleet_Command
@Jdlrobson-WMF
Oh of course, that completely makes sense.
Yes, it sounds like a sensible plan to ship for Parsoid first. I'd be happy to help beta-test something, if that would be useful.
cscott
added a comment.
Feb 10 2026, 9:44 PM
2026-02-10 21:44:41 (UTC+0)
Comment Actions
Given the usage stats in
T375981#11527458
it seems like having "small" be 180px would be best to accommodate the 1.7 million users who have that as their preferred thumbnail size.
Current settings in wmf-config default to 250px for every wiki. itwikiquote has an additional option of 360px (for some reason) and svwiki has reduced the number of available default sizes to five (120, 200, 250, 300, 360).
T360589
quantized the generated
img src
for all parsers (including parsoid) so we do already do downscaling via the
width
attribute for images of specific sizes.
I believe the current plan is to reduce the user thumbnail size preferences to three: "small", "standard", and "large". Small would be 180px, standard is 250px; I'm not sure exactly how large "large" should be, but 300/360/400 seems to be the available options.
Ladsgroup
added a comment.
Feb 10 2026, 9:49 PM
2026-02-10 21:49:13 (UTC+0)
Comment Actions
In
T375981#11604710
@cscott
wrote:
Given the usage stats in
T375981#11527458
it seems like having "small" be 180px would be best to accommodate the 1.7 million users who have that as their preferred thumbnail size.
FWIW, it's not organic. 180px was the default for a long time and they wanted to change it to 250px for new users, so the default was switched to 250px and every existing user had it back filled to 180px. For really long time, I thought German Wikipedia has a weird default for thumbnails until I realized it wasn't my decision. Once cleaned, the wiki looked normal to me.
gerritbot
added a comment.
Feb 11 2026, 1:52 AM
2026-02-11 01:52:07 (UTC+0)
Comment Actions
Change #1238463 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):
[mediawiki/core@master] POC: Set thumbnail sizes via config
Ladsgroup
added a comment.
Feb 11 2026, 2:07 PM
2026-02-11 14:07:15 (UTC+0)
Comment Actions
After the clean up of user properties (
T406724
). The number of users that have their thumb set to 180px is now down to 150K in enwiki. I assume overall, it should be around 500K at most.
cscott
mentioned this in
T417513: Switch to CSS/JS solution for thumbnail size in legacy parser
Feb 15 2026, 9:29 PM
2026-02-15 21:29:32 (UTC+0)
cscott
created subtask
T417514: Remove `thumbsize` from ParserOptions
cscott
mentioned this in
T417514: Remove `thumbsize` from ParserOptions
cscott
created subtask
T417515: Parsoid should include 4x image size in srcset to accomodate large thumbsize preferences
Feb 15 2026, 9:34 PM
2026-02-15 21:34:24 (UTC+0)
cscott
mentioned this in
T417515: Parsoid should include 4x image size in srcset to accomodate large thumbsize preferences
cscott
created subtask
T417516: Thumbnail sizes should be configurable
Feb 15 2026, 9:38 PM
2026-02-15 21:38:09 (UTC+0)
cscott
mentioned this in
T417516: Thumbnail sizes should be configurable
gerritbot
added a comment.
Feb 15 2026, 10:05 PM
2026-02-15 22:05:05 (UTC+0)
Comment Actions
Change #1227492
merged
by jenkins-bot:
[mediawiki/core@master] Support CSS/JS thumbnail sizing in Parsoid
ReleaseTaggerBot
added a project:
MW-1.46-notes (1.46.0-wmf.16; 2026-02-17)
Feb 15 2026, 11:00 PM
2026-02-15 23:00:10 (UTC+0)
SomeRandomDeveloper
subscribed.
Feb 18 2026, 9:37 PM
2026-02-18 21:37:32 (UTC+0)
cscott
mentioned this in
T417828: Some images become disproportionately big in 1.46.0-wmf.16
Feb 18 2026, 10:32 PM
2026-02-18 22:32:49 (UTC+0)
Comment Actions
The patch for this task caused a regression in production and was reverted:
T417828: Some images become disproportionately big in 1.46.0-wmf.16
cscott
added a comment.
Edited
Feb 18 2026, 11:03 PM
2026-02-18 23:03:28 (UTC+0)
Comment Actions
In
T417828#11630071
@cscott
wrote:
This was part of an experiment to support user-customizable thumbnail sizes in Parsoid output (
T375981: Preferences settings for small image size are not being respected for Parsoid Read Views
). Parsoid sets
mw-default-size
to indicate images which don't have a width or height set in the wikitext, which are generally then used at the wiki's default thumbnail size. The thing we missed in review was that this applies *only if the image is natively larger than the default thumbnail size*; we never upscale an image to meet the default thumbnail size.
This is probably a deficiency in Parsoid's Mediawiki DOM Spec output: although we have the information about the native image size available (in the
data-file-width
and
data-file-height
attributes), I don't believe CSS can natively do a "less than" query on these attribute values, so there's no way to write the "correct" CSS here. I think Parsoid is going to have to either:
Only emit the
mw-default-size
class for images that are greater than/equal the thumbnail size, or
Add a separate class for "not upscaled" images, so that the CSS can know to leave them alone.
There's an added wrinkle here, in that the "thumbnail size" is user-customizable. So if the user thumbnail size preferences are 180, 250, and 400 (say), images which are 200px wide will be scaled down for the "small" thumbnail size preference but not scaled up for the "standard" and "large" preferences. Similarly, and image which is natively 300px will be scaled down for small and standard thumbnail size preferences but not for the 'large' one. These breakpoints are going to have to be hardcoded in Parsoid as well if it is to emit classes to distinguish these cases. Hmm.
Some proposed solutions:
Add
mw-not-upscaled
class to images with a "natural size" less than the default thumbnail size (250px in this case). This still leads to slightly different behavior between legacy and Parsoid for images with sizes in between the smallest and largest thumbnail size, but I think that's probably acceptable. For example, a 200px image would be rendered at 200px, even if the user selected "small" thumbnail size (usually 180px), whereas legacy would scale it down for "small" but leave it natural for "standard" and "large" thumbnail sizes. Similarly, a 300px image would be scaled to match the selected thumbnail size (including upscaling to 400px for "large") whereas the legacy behavior would be to scale it down for small and standard but leave it as its natural size for "large" thumbnail size. I think these slightly different behaviors would be acceptable; they would only be visible to users with non-default thumbnail size preferences.
An alternative would be to create separate classes for
mw-not-upscaled-small
mw-not-upscaled-standard
and
mw-not-upscaled-large
based on the wiki size breakpoints (currently 180px, 250px, and 400px), which would allow exact reproduction of the legacy behavior, at the cost of more complexity in the CSS, HTML, and code. (Images below 180px would get
mw-not-upscaled-small
and would never be rescaled to the thumbnail size preference; images between 180px and 249px would get
mw-not-upscaled-standard
and would get only get rescaled to the default thumbnail size if the user's thumb preference is "small"; images between 250px and 399px would get
mw-not-upscaled-large
and would get rescaled to the default thumbnail size unless the user's thumb preference is "large".)
Leave the HTML alone, but use the existing intersection observer on images to suppress scaling (it could add the same
mw-not-upscaled
class) based on the data-file-width attributes on the image.
ssastry
subscribed.
Edited
Feb 19 2026, 1:55 AM
2026-02-19 01:55:47 (UTC+0)
Comment Actions
I think we should go with option 3. It doesn't require changing Parsoid, the HTML spec, and also doesn't introduce infrastructure-config-based classes into the output HTML. We should use JS to look up the data-* attributes and add the appropriate CSS classes.
Jdlrobson
subscribed.
Edited
Feb 19 2026, 5:03 AM
2026-02-19 05:03:37 (UTC+0)
Comment Actions
I dont think 3 works here will work without some kind of performance penalty e.g cumulative layout shift.
Can we not change the CSS selectors to
.mw-default-size[data-file-width=250]
or
.mw-default-size[width=250]
? I think this would be equivalent to 1.
cscott
merged a task:
T417828: Some images become disproportionately big in 1.46.0-wmf.16
Feb 19 2026, 3:19 PM
2026-02-19 15:19:50 (UTC+0)
cscott
added subscribers:
Daimona
Valepert
Izno
SomeRandomDeveloper
unsubscribed.
Feb 19 2026, 3:27 PM
2026-02-19 15:27:16 (UTC+0)
SomeRandomDeveloper
subscribed.
gerritbot
added a comment.
Feb 19 2026, 5:01 PM
2026-02-19 17:01:10 (UTC+0)
Comment Actions
Change #1240756 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
[mediawiki/core@master] Fix CSS/JS thumbnail sizing in Parsoid: don't upscale small images
cscott
added a comment.
Edited
Feb 19 2026, 5:01 PM
2026-02-19 17:01:53 (UTC+0)
Comment Actions
@Jdlrobson
ok, implemented your idea in
Fix CSS/JS thumbnail sizing in Parsoid: don't upscale small images (1240756)
data-file-width
would do the wrong thing, since that is 'natural width', but I've tested that
[width=250]
works as you'd expect. As described in option 1, there are some corner cases where we don't rescale but I think they are reasonable.)
gerritbot
added a comment.
Feb 20 2026, 5:13 PM
2026-02-20 17:13:02 (UTC+0)
Comment Actions
Change #1240756
merged
by jenkins-bot:
[mediawiki/core@master] Fix CSS/JS thumbnail sizing in Parsoid: don't upscale small images
ReleaseTaggerBot
edited projects, added
MW-1.46-notes (1.46.0-wmf.17; 2026-02-24)
; removed
MW-1.46-notes (1.46.0-wmf.16; 2026-02-17)
Feb 20 2026, 6:00 PM
2026-02-20 18:00:31 (UTC+0)
cscott
moved this task from
Q4 FY25-26
to
To Deploy
on the
Content-Transform-Team (Work In Progress)
board.
Feb 23 2026, 4:36 PM
2026-02-23 16:36:37 (UTC+0)
cscott
added a subscriber:
Arlolra
Edited
Feb 23 2026, 6:07 PM
2026-02-23 18:07:48 (UTC+0)
Comment Actions
@Arlolra
notes that this CSS/JS solution also doesn't scale images which use the
upright
option (
). That's not a regression -- we didn't scale those thumbnails before because we didn't scale any thumbnails -- and might be something we address with a new wikitext option, like
square
. CF
Add a new image option: "square" (120856)
T351: RfC: Square bounding boxes
T65903: Thumbnails should use a square bounding box by default
T37756: Image parameter for thumbs that scale to an exact box, cropping as necessary
T65904: The 'upright' option should use a square bounding box
T9003: Allowthumbnail size of an image to be defined as proportion of the user's default
, etc.
is relevant, too.
It might be that a JS intersection observer is necessary to handle the arbitrary scaling possible with 'upright'.
cscott
moved this task from
To Deploy
to
To Verify
on the
Content-Transform-Team (Work In Progress)
board.
Mar 2 2026, 4:18 PM
2026-03-02 16:18:28 (UTC+0)
Jdlrobson-WMF
added a comment.
Mar 12 2026, 10:25 PM
2026-03-12 22:25:08 (UTC+0)
Comment Actions
Hi
@Mr._Starfleet_Command
and
@OwenBlacker
could you try this out for us? If you enable parsoid do thumbnails now work how you'd expect?
OwenBlacker
added a comment.
Mar 13 2026, 10:10 AM
2026-03-13 10:10:47 (UTC+0)
Comment Actions
I'm afraid it does not.
If I go look at the
London on enwiki
, I'm seeing some images larger (perhaps because they have hardcoded sizes?) but below is what I'm seeing in the History section.
All sizes are what Chrome dev tools are telling me; ❌ are noting differences I would not expect, ✅ are where Parsoid is using a different intrinsic image size from the Legacy parser, but is still downscaling to the render, which is the behaviour I was expecting to see. No emoji indicates no change between the 2 parsers.
Image
Legacy render
Parsoid render
Legacy intrinsic
Parsoid intrinsic
File:Stelalondon.jpg
215 × 225
215 × 225
500 × 524
500 × 524
File:London Wall fragment.jpg
215 × 161
215 × 161
500 × 375
500 × 375
File:Westminster Abbey by Canaletto, 1749.jpg
392 × 383
392 × 383
960 × 937
250 × 244 ❌
File:Siege of London (MS 1168).jpg
292 × 445
182 × 227
250 × 381
250 × 381
File:London - John Norden's map of 1593.jpg
392 × 368
392 × 368
960 × 902
960 × 902
File:Great Fire London.jpg
472 × 275
292 × 170 ❌
960 × 779
500 × 291 ✅
File:Edward Angelo Goodall04.jpg
292 × 390
182 × 243 ❌
500 × 667
330 × 440 ✅
File:Fotografi av Royal Exchange. London, England - Hallwylska museet - 105857.tif
392 × 324
392 × 324
600 × 496
375 × 310 ❌
File:British recruits August 1914 Q53234.jpg
220 × 159
220 × 159
500 × 360
330 × 238 ✅
File:LondonBombedWWII full.jpg
220 × 157
220 × 157
500 × 357
330 × 236 ✅
I note that the Canaletto image (3rd in that list) and the Royal Exchange photo (8th) are being
up
scaled by Parsoid, but
down
scaled by the Legacy parser. To my (aging) eyes, the Canaletto Parsoid upscale look slightly sharper but the reverse is true for the Royal Exchange TIFF, for what it's worth 🤷🏼
On a simpler example,
City Hall, London (Newham) on enwiki
is showing me a 440 × 225 version of File:Siemens Crystal Building, London.jpg in the infobox on the Legacy parser, but Parsoid is showing me a 280 × 162 image, both being downscaled from 960 × 557.
Jdlrobson-WMF
added a comment.
Mar 13 2026, 10:02 PM
2026-03-13 22:02:40 (UTC+0)
Comment Actions
@OwenBlacker
thanks for looking. I am seeing slight differences in the numbers you are sharing. What dpi and thumbnail preference are you testing on?
With 400px set, inspecting File:Westminster Abbey by Canaletto, 1749.jpg I see 500 × 488 px for legacy as intrinsic size in Parsoid and 960 × 937 px for legacy.
You said before "For what it's worth, I am one of the 53k users who has the pref set to 400px and in my case it is for accessibility." so to be precise I'm keen to know what specifically here impacts your accessibility needs? I'm not looking to get the numbers exact, but in similar ballpark. We should be able to get File:Westminster Abbey by Canaletto, 1749.jpg and File:Fotografi av Royal Exchange. London, England - Hallwylska museet - 105857.tif using high resolution images in Parsoid.
Regarding Siege of London, File:Great Fire London.jpg, File:Edward Angelo Goodall04.jpg: While working on this we uncovered some weirdness in how upright works (flagged here:
T375981#11641808
) that we are thinking through.
@cscott
I have some questions based on this example:
On a simpler example, City Hall, London (Newham) on enwiki is showing me a 440 × 225 version of File:Siemens Crystal Building, London.jpg in the infobox on the Legacy parser, but Parsoid is showing me a 280 × 162 image, both being downscaled from 960 × 557.
I'm a bit confused why legacy scales this one - as the infobox itself is specifying this should render at 280px and the thumbnail preference is not supposed to tweak images with specified width. Any idea what might be happeneing here? Is this a bug in legacy?
something seems to be off here in the Parsoid output. Legacy parser has a srcset of
//upload.wikimedia.org/wikipedia/commons/thumb/7/79/Westminster_Abbey_by_Canaletto%2C_1749.jpg/960px-Westminster_Abbey_by_Canaletto%2C_1749.jpg 1.5x
Whereas Parsoid has a srcset of
//upload.wikimedia.org/wikipedia/commons/thumb/7/79/Westminster_Abbey_by_Canaletto%2C_1749.jpg/500px-Westminster_Abbey_by_Canaletto%2C_1749.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/7/79/Westminster_Abbey_by_Canaletto%2C_1749.jpg/500px-Westminster_Abbey_by_Canaletto%2C_1749.jpg 2x
e.g. 1.5x and 2x are identical.
I would expect Parsoid to output 500px for 1.5x and 960px for 2x
e.g.
//upload.wikimedia.org/wikipedia/commons/thumb/7/79/Westminster_Abbey_by_Canaletto%2C_1749.jpg/500px-Westminster_Abbey_by_Canaletto%2C_1749.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/7/79/Westminster_Abbey_by_Canaletto%2C_1749.jpg/960px-Westminster_Abbey_by_Canaletto%2C_1749.jpg 2x
Jdlrobson-WMF
moved this task from
Blockers
to
Thumbnail simplification
on the
Readers Essential Work (WE6.3.4 Fix bugs within the reading experience across platforms for Parsoid Read Views)
board.
Mar 13 2026, 10:11 PM
2026-03-13 22:11:57 (UTC+0)
cscott
added a comment.
Mar 16 2026, 11:28 PM
2026-03-16 23:28:26 (UTC+0)
Comment Actions
T419927: PNGs are being displayed at a too-low, blurry resolution
was fixed very recently and just backported today
Revert "mediawiki.util: Prefer prev step over non-standard in adjustThumbWidthForSteps" (1253518) · Gerrit Code Review
I wonder if that might explain some of your inconsistent results.
Parsoid uses the core imageinfo APIs, and so in theory should be getting exactly the same srcset that core is getting, but given that this code base is (apparently) under active development, it might be safest to use
?action=purge
to ensure that you're actually testing the same thumbnail code on Parsoid and legacy at the same time.
Jdlrobson-WMF
closed subtask
T417516: Thumbnail sizes should be configurable
as
Resolved
Mar 17 2026, 12:08 AM
2026-03-17 00:08:45 (UTC+0)
gerritbot
added a comment.
Mar 18 2026, 12:24 AM
2026-03-18 00:24:42 (UTC+0)
Comment Actions
Change #1254377 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):
[mediawiki/core@master] Skins: Address issue with blurry images for large thumbnails
OwenBlacker
added a comment.
Edited
Mar 19 2026, 1:21 PM
2026-03-19 13:21:42 (UTC+0)
Comment Actions
@Jdlrobson-WMF
The specific accessibility issue is just poor eyesight, even when corrected by glasses. I have a global pref set for 400px thumbnails and both then and now I am using my dayjob 14" MacBook Pro M5 on “Apple XDR Display (P3-1600 nits)”, if that helps? When I tell it to show resolutions as a list, it says I'm running at the default 1512×982.
Incidentally, I saw another curiosity about image sizing just now (which I can raise as a separate ticket if you need). I was looking at enwiki:Éric_Hazan and the infobox image is being stretched by a style rule from
, reading
html
skin-theme-clientpref-thumb-large
mw-parser-output
data-mw-parsoid-version
mw-default-size
img
width
400
px
without which Chrome Inspector says the
img
has a width of 249.702px
I took a screenshot and uploaded it as
c:File:Example of Parsoid image rendering bug 2026-03-19.png
Clicking through to other articles, it looks like all infobox images are being similarly stretched
Jdlrobson-WMF
added a comment.
Mar 19 2026, 3:44 PM
2026-03-19 15:44:34 (UTC+0)
Comment Actions
Incidentally, I saw another curiosity about image sizing just now
Thanks to your feedback I already found this one (and a related issue) which should be fixed in the patch above (
). This will not help images using upright which I'm still thinking through but it should reduce the blur factor for you on some images.
Hoping to improve this for you over the next 1-2 weeks!
gerritbot
added a comment.
Mar 19 2026, 8:48 PM
2026-03-19 20:48:11 (UTC+0)
Comment Actions
Change #1254377
merged
by jenkins-bot:
[mediawiki/core@master] Skins: Address issue with blurry images for large thumbnails
gerritbot
added a comment.
Mar 19 2026, 8:55 PM
2026-03-19 20:55:16 (UTC+0)
Comment Actions
Change #1255774 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
[mediawiki/services/parsoid@master] Add `class` and `style` attributes for upright images
ReleaseTaggerBot
edited projects, added
MW-1.46-notes (1.46.0-wmf.21; 2026-03-24)
; removed
MW-1.46-notes (1.46.0-wmf.17; 2026-02-24)
Mar 19 2026, 9:00 PM
2026-03-19 21:00:42 (UTC+0)
gerritbot
added a comment.
Mar 19 2026, 9:10 PM
2026-03-19 21:10:02 (UTC+0)
Comment Actions
Change #1255881 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):
[mediawiki/core@wmf/1.46.0-wmf.20] Skins: Address issue with blurry images for large thumbnails
gerritbot
added a comment.
Mar 19 2026, 9:22 PM
2026-03-19 21:22:03 (UTC+0)
Comment Actions
Change #1255881
merged
by jenkins-bot:
[mediawiki/core@wmf/1.46.0-wmf.20] Skins: Address issue with blurry images for large thumbnails
Stashbot
added a comment.
Mar 19 2026, 9:22 PM
2026-03-19 21:22:25 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-operations)
[2026-03-19T21:22:24Z]
T375981
)]]
Stashbot
added a comment.
Mar 19 2026, 9:24 PM
2026-03-19 21:24:18 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-operations)
[2026-03-19T21:24:17Z]
T375981
)]] synced to the testservers (see
). Changes can now be verified there.
Stashbot
added a comment.
Mar 19 2026, 9:29 PM
2026-03-19 21:29:28 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-operations)
[2026-03-19T21:29:27Z]
T375981
)]] (duration: 07m 03s)
Jdlrobson-WMF
added a comment.
Mar 19 2026, 9:52 PM
2026-03-19 21:52:25 (UTC+0)
Comment Actions
@OwenBlacker
this should be working a lot better now. There is still a lack of support with upright parameter but working on that in
T420657: Preferences settings for small image size are not compatible with upright for Parsoid Read Views
. Do things seem less blurry now? (Sorry I'm starting to sound like your optician!)
ReleaseTaggerBot
edited projects, added
MW-1.46-notes (1.46.0-wmf.20; 2026-03-17)
; removed
MW-1.46-notes (1.46.0-wmf.21; 2026-03-24)
Mar 19 2026, 10:00 PM
2026-03-19 22:00:34 (UTC+0)
Jdlrobson-WMF
lowered the priority of this task from
Medium
to
Low
Mar 23 2026, 9:58 PM
2026-03-23 21:58:37 (UTC+0)
Jdlrobson-WMF
closed this task as
Resolved
Thu, Mar 26, 11:20 PM
2026-03-26 23:20:58 (UTC+0)
Comment Actions
Parsoid now has support for small, regular and large images. We may decide to expand this solution to the legacy parser in future to improve cacheability in
T417513: Switch to CSS/JS solution for thumbnail size in legacy parser
Note in some cases, the thumbnails served in Parsoid differ from the legacy parser, but they should achieve the same goal (of less blurry images).
@OwenBlacker
and
@Mr._Starfleet_Command
if you have any feedback/concerns about the solution we landed on I would appreciate hearing about them either has a comment to this ticket or a new bug report (please subscribe me!) and we'll see what we can do about it.
I appreciate both your input on helping us reach this solution.
Jdlrobson-WMF
closed subtask
T417515: Parsoid should include 4x image size in srcset to accomodate large thumbsize preferences
as
Declined
Fri, Apr 3, 9:14 PM
2026-04-03 21:14:54 (UTC+0)
Johannnes89
subscribed.
Fri, Apr 10, 7:19 PM
2026-04-10 19:19:02 (UTC+0)
Johannnes89
mentioned this in
T423676: Infobox images have huge padding in Firefox
Fri, Apr 17, 8:55 AM
2026-04-17 08:55:39 (UTC+0)
Log In to Comment
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct.
Wikimedia Foundation
Code of Conduct
Disclaimer
CC-BY-SA
GPL
Credits
US