The zoom level in both browsers (Chrome and Firefox) is set to 100 %. Sorry for the priority triage, I thought it's ok to do so.

Hmm, I guess I can reproduce in Firefox 84 on Linux on 100% zoom, comparing how the same thumbnail PNG is rendered in two different places:

Change 656893 had a related patch set uploaded (by Noam Rosenthal; owner: Noam Rosenthal):
[mediawiki/extensions/Popups@master] Amend image size when clip-path is present Use original image size and clip with fixed size, instead of using object-fit: cover which caused the image to change its size.

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

I can replicate this on browser stack in Windows and now understand the issue some more.

$('<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Computer_modern_sample.svg/640px-Computer_modern_sample.svg.png">').css({ 'object-fit': 'cover', width: '320px', 'min-height': '200px'}).appendTo('#content')

The image is 640px by 270px so it's not possible for it to be 320px x 200px without some blur. Ideally it would render at 320px by 135px.

@Nomsterio I see several other options here

1. We request a bigger thumbnail. Perhaps the blur will go away? Note we're not rendering an SVG here, we're rendering a PNG version of an svg (don't ask ;-))
2. Perhaps we could use object-fit: contain when we know the thumbnail is going to be under 200px height or always use object-fit: contain?
3. Perhaps we live with the bug, and call it a Windows bug, and report upstream. We might browser sniff and disable the new clip-path behaviour for Windows in the mean time.

I'm also curious of this bug was related to your clip-path change or as been present for some time and we just didn't notice.

In T272169#6769738, @Jdlrobson wrote:

3. Perhaps we live with the bug, and call it a Windows bug, and report upstream. We might browser sniff and disable the new clip-path behaviour for Windows in the mean time.

Windows only bug? Aklapper presumably reproduced the bug in Linux too:

In T272169#6751977, @Aklapper wrote:

Hmm, I guess I can reproduce in Firefox 84 on Linux on 100% zoom, comparing how the same thumbnail PNG is rendered in two different places:

In T272169#6769738, @Jdlrobson wrote:

I can replicate this on browser stack in Windows and now understand the issue some more.

$('<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Computer_modern_sample.svg/640px-Computer_modern_sample.svg.png">').css({ 'object-fit': 'cover', width: '320px', 'min-height': '200px'}).appendTo('#content')

The image is 640px by 270px so it's not possible for it to be 320px x 200px without some blur. Ideally it would render at 320px by 135px.

@Nomsterio I see several other options here

1. We request a bigger thumbnail. Perhaps the blur will go away? Note we're not rendering an SVG here, we're rendering a PNG version of an svg (don't ask ;-))

That's what the original code did, and in the attached change request I mimic that original behavior: loading a bigger PNG and clipping it.

2. Perhaps we could use object-fit: contain when we know the thumbnail is going to be under 200px height or always use object-fit: contain?

That's a design decision, the thumbnail might look a bit odd though.
I think that to avoid blurriness altogether, something that might work would be to load the thumbnail in integer multiplies of its original size to cover the thumbnail area, and clip it to the thumbnail area. I wish there was an object-fit that does that!

3. Perhaps we live with the bug, and call it a Windows bug, and report upstream. We might browser sniff and disable the new clip-path behaviour for Windows in the mean time.

I'm also curious of this bug was related to your clip-path change or as been present for some time and we just didn't notice.

Yes, it was related, and the change request attached fixes it to use the same logic as before.

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

I think that to avoid blurriness altogether, something that might work would be to load the thumbnail in integer multiplies of its original size to cover the thumbnail area, and clip it to the thumbnail area. I wish there was an object-fit that does that!

I talked to my product today, and we'd prefer to request the larger thumbnail.
My understanding is this would be changing the line in src/constants.js to THUMBNAIL_SIZE: 320 * Math.max(1.5, bpr), with a comment documenting it pointing to this ticket.

If that doesn't work, we're okay with leaving this blurred for now unless we can find a simpler solution. Our guess is the percentage of thumbnails impacted is quite low.

Change 658493 had a related patch set uploaded (by Noam Rosenthal; owner: Noam Rosenthal):
[mediawiki/extensions/Popups@master] Fix bluriness on low-DPR screens

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

In T272169#6776297, @gerritbot wrote:

Change 658493 had a related patch set uploaded (by Noam Rosenthal; owner: Noam Rosenthal):
[mediawiki/extensions/Popups@master] Fix bluriness on low-DPR screens

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

@Jdlrobson the new patch does exactly that, seems to be the most sensible and simple solution to me.

Change 658493 merged by jenkins-bot:
[mediawiki/extensions/Popups@master] Fix bluriness on low-DPR screens

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

@Jdlrobson is there a link in Beta where the blurring of the image occurred?

@Edtadros Sadly not. I think this needs to be QA in production. For beta cluster, let's just do some exploratory testing, making sure page previews render with thumbnails as expected.

Our guess is the percentage of thumbnails impacted is quite low.

I assume that about 5–10 % of page previews with images are affected on cswiki (my rough estimate based on browsing while past days). It's not very usual, but it's not rare neither.

Change 656893 abandoned by Jdlrobson:
[mediawiki/extensions/Popups@master] Amend image size when clip-path is present Use original image size and clip with fixed size, instead of using object-fit: cover which caused the image to change its size.

Reason:
Addressed by https://gerrit.wikimedia.org/r/658493

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

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: Windows 10 (Browserstack)
Browser: Firefox
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

✅ AC1: Performed exploratory testing per T272169#6778733. Thumbnails all appeared as expected without looking blurry.

If I'm reading the new code correctly, this gets us from these thumbnails width being used:

• 320px for devices rounded to 1 dpr
• 480px for devices rounded to 1.5 dpr
• 640px for devices rounded to 2 dpr

To:

• 480 for devices rounded to 1 or 1.5 dpr
• 640 for devices rounded to 2 dpr

Are we certain that this issue was only affecting users with devices bucketed to 1 dpr?

In regards to thumbnail caching, based on 2018 data 480 is a lot less common than 320, but at the same time with this change Page Previews will only be requesting 2 different widths instead of 3, which means that 480px thumbnails will get hotter by covering devices rounded to both 1 and 1.5dpr. I'm not sure that we have stats about device dpr as exposed by clients. We used to when MediaViewer used to collect that kind of data, but I believe that was stopped at some point in the last couple of years.

At any rate I expect that 480px thumbnails will get hot pretty quickly for users in the 1dpr bucket, as in most cases they would have already been warmed up by 1.5 users.

Fix has not made it into production yet. cs.wiki is still on 1.36.0-wmf.27 [1]

[1] https://cs.wikipedia.org/wiki/Speci%C3%A1ln%C3%AD:Verze