Basically it looks like it's returning a url for a size variant which doesn't exceed thumbwidth, but not necessarily the size variant closest-to-and-not-exceeding thumbwidth.

Another example showcasing the bug:

https://en.wikipedia.org/w/api.php?action=mobileview&format=jsonfm&page=information&thumbwidth=640&prop=thumb

"url":
     "//upload.wikimedia.org/wikipedia/commons/thumb/b/bb/WikipediaBinary.svg/88px-WikipediaBinary.svg.png",
     "width": 88,
     "height": 106
   },

Oh interesting! It may be only happening for SVG images... can you confirm @MaxSem ?

Thanks for all of the detail @Mhurd. What's the priority of this bug on your side? I'd like to put this through the normal Web-Team-Backlog process and knowing if it needs to be fixed sharpish would help.

Hey @phuedx, I'd say it's medium to high priority.

@BGerstle-WMF @Fjalapeno

Hey guys didn't realize you weren't tagged on this. I added a screen shot.

There is a dupe of this card in iOS sprint 59: https://phabricator.wikimedia.org/T99126.

I recommend we close that ticket and instead pull this one into sprint 59. Let's do this thing :)

@JKatzWMF here's a ticket that will improve some upstream bits :)

I'm recommending we pull this into the next iOS sprint and work with whoever to make it happen.

@Mhurd does this impact android as well? This seems like a reasonable thing to work on, but I think prioritization for this falls in the hands of @Fjalapeno, @Dbrant and @phuedx : TechPMs let me know if you want to discuss prioritization.

Yes, this does affect Android as well.

Is this limited to SVGS? I see the width and height being returned is the preview size on https://en.m.wikipedia.org/wiki/File:Wikipedia-v2-logo.svg

Going to have a good look at this next sprint.

@Mhurd can you help @Jdlrobson ^ and confirm it only happens with svgs? Thanks!

@Jhernandez yes it's only happening with SVGs.

@Jdlrobson

Ah you're right, it's returning the first, lowest resolution preview size! The problem is it's ignoring the requested thumbwidth parameter. I believe the desired behavior is for it to return the preview size closest to (but not exceeding) the requested thumbwidth.

In the example in the ticket description, a thumbwidth of 640 is sought. So the "526 × 480 pixels" variant would be the closest match, not the "103 × 94 pixels" variant it's presently returning.

In mean time this could be worked around like so:

• If SVG..
  • take height / width to get ratio e.g. h / w = 106 / 88 = 1.204...
  • Multiply desired width by ratio to get height e.g. 640 * ratio = 771px

@bmansurov any findings from your time on this bug? No matter how small they might be enlightening - even if they are "this is hard" :)

@Jdlrobson, I haven't been able to get the API return a thumbnail of an SVG yet. I may have time to investigate more today.

@JMinor Can you escalate this to high if this needs attention from the web team (or comment on its relative priority)?

While I tend to agree that this is a bug, I think the thumb request API logic is working as expected: when a thumb of width greater than the original image size is requested, a link is returned for the file at the original dimensions. Here, the original (nominal) dimensions are 103px by 94px,[1] so that's what it returns dimensions and a link for. (Request a smaller size, and you'll see that the specified size is honored.[2])

For most file formats, that's what we want, because the thumbnailing engine won't render a thumbnail larger than the original.[3] However, SVGs are exceptional because they can be scaled arbitrarily, which the thumbnailing engine will in fact do for us.[4]

So I think the real fix is to create an exception for SVGs to the rule that the API won't return thumbnail results for a size larger than the original, and instead return results for arbitrarily large sizes for SVGs (within some reasonable limit). This would probably have to happen somewhere in MW core, where I think the core scaling logic lives. In the meantime I agree with @Jdlrobson that we could work around this on the client by detecting when we're dealing with an SVG and rewriting the size in the URL to whatever we want in that case.

[1] https://en.wikipedia.org/wiki/File:Wikipedia-logo-v2.svg
[2] https://en.wikipedia.org/w/api.php?action=mobileview&format=jsonfm&page=wikipedia&thumbwidth=80&prop=thumb
[3] https://upload.wikimedia.org/wikipedia/commons/thumb/8/8d/President_Barack_Obama.jpg/9999px-President_Barack_Obama.jpg
[4] https://upload.wikimedia.org/wikipedia/en/thumb/8/80/Wikipedia-logo-v2.svg/9999px-Wikipedia-logo-v2.svg.png

Upon further investigation, this isn't getting constrained in MW core, but actually by this bit of logic in MobileFrontend:

https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/api/ApiMobileView.php#L738-L743

In Monte's query in the description, for example, there's no thumbheight specified, so a height of 94px is getting set based on the (nominal) height of the original, and that value's then constraining the overall size when the thumbnail is generated. Omit adding these constraints and MediaWiki will happily give us a thumb and URL for any* size we specify for an SVG.

It would be easy to just add a check to skip adding these constraints based on the original file dimensions when $file->getMimeType() === "image/svg", but is there any reason to add these constraints in MobileFrontend at all rather than simply relying on the normalization logic in MW core?

*(subject to any maximum set in the global variable $wgSVGMaxSize)

Change 334791 had a related patch set uploaded (by Mholloway):
Don't constrain SVG thumb requests based on the original file size

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

Change 334791 merged by jenkins-bot:
Don't constrain SVG thumb requests based on the original file size

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