Page MenuHomePhabricator

Regression: Page-Previews seem to be blurred for thumbnails with natural height less than 200px.
Closed, ResolvedPublic3 Estimated Story PointsBUG REPORT

Description

When I hover over links to some pages, the images in the page previews seem to be blurred. (Although the images themselves have good quality.)

Images

from articles

on Commons:

Some articles seem to be unaffected (or at least not affected so much). I use Win10, this problem doesn't depend on web browser, my screen resolution is 1920x1080px.

QA steps

QA Results - Beta

ACStatusDetails
1T272169#6783768

QA Results - Prod

ACStatusDetails
1T272169#6852604

Event Timeline

Aklapper raised the priority of this task from High to Needs Triage.Jan 15 2021, 5:47 PM

Hi @Draceane, thanks for taking the time to report this!
What is your browser zoom level in the browser? Is it set to 100% ?
(I'm also resetting priority, plus this does not look like high priority.)

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

ovasileva renamed this task from Page-Previews seem to be blurred to Regression: Page-Previews seem to be blurred.Jan 21 2021, 6:14 PM
ovasileva set the point value for this task to 3.Jan 21 2021, 6:19 PM

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.

Jdlrobson renamed this task from Regression: Page-Previews seem to be blurred to Regression: Page-Previews seem to be blurred for thumbnails with natural height less than 200px..Jan 22 2021, 6:55 PM
  1. 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:

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:

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.

  1. 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!

  1. 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

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.

Edtadros added a subscriber: Edtadros.

Test Result - Prod

Status: ❌ FAIL
Environment: cswiki
OS: Windows 10 (Browserstack)
Browser: Firefox
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

Visit https://cs.wikipedia.org/w/index.php?title=Wikipedie:Pod_l%C3%ADpou_(technika)&oldid=19385740#Obr%C3%A1zky_ve_vyskakovac%C3%AD_karti%C4%8Dk%C3%A1ch in Windows 10 IE11 Firefox
Hover over "Computer Modern"
❌ AC1: Expected: image is not blurred

Edtadros updated the task description. (Show Details)

This is testable now in production.

Test Result - Prod

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

Test Artifact(s):

QA Steps

Visit https://cs.wikipedia.org/w/index.php?title=Wikipedie:Pod_l%C3%ADpou_(technika)&oldid=19385740#Obr%C3%A1zky_ve_vyskakovac%C3%AD_karti%C4%8Dk%C3%A1ch in Windows 10 IE11 Firefox
Hover over "Computer Modern"
✅ AC1: Expected: image is not blurred