Portrait images (called "tall" in the code, i.e. their height is larger than their width) are massively cut on **all 4** sides:
{F31866428}
The blue rectangle in this screenshot is the actual thumbnail, cut off on all 4 sides. For reference (notice how the building on the right is more visible):
{F31866427}
This does not happen for landscape images. I tried to understand why this happens, when it was introduced, and if it was a concisus decision to do so. As far as I can tell, no, this is a bug. This happens because:
* The #PageImages API is used to request the thumbnail. It's requested with a single `320` number to be the length of the largest side.
* The API returns a thumbnail with, in this example, 240 x 320 pixels.
* However, Popups uses this image as an unscaled background image for a rectangle that is at most 203 x 250 pixels. The responsible code doesn't even care how large the thumbnail is. It always shows a 203 x 250 cutout only. It's like this code expects the thumbnail to be 250 pixels high, but it's not.
Reported here: https://www.mediawiki.org/wiki/Topic:Vo876rts2zg2bvrh
A proper algorithm would request a thumbnail that fits in a 320 x 250 rectangle. MediaWiki can do this, but unfortunately the PageImages API doesn't. There is a single `thumbsize` parameter only. So a fixed algorithm might look like this:
* Request a thumbnail that fits in 320 x 320 pixels.
* If it's a landscape image, just use it as it is. The popup is 320 pixels wide as well. All landscape images fit perfectly.
* If it's a portrait image, scale it down so it fits in the available 250 pixel height. "Scaling" here means simply setting the width and height to values that are scaled down a bit. The browser will do the scaling.
== Acceptance criteria
- [] When fixing this issue, please consider adding the use case as a Storybook story so we can verify future changes don't regress.