Page MenuHomePhabricator

[SPIKE 4hrs] letters become fuzzy after scrolling in some articles in Chrome in Vector 2022
Closed, ResolvedPublic1 Estimated Story PointsSpike

Description

Steps to replicate the issue (include links if applicable):

  • Use Chrome on Windows (Chrome 107.0.5304.107, Windows 10) on the desktop.
  • Open a private browser window. Don't log in to Wikipedia.
  • Open the article https://he.wikipedia.org/wiki/BTS.
  • Scroll down.

What happens?:

  • Towards the end of the infobox, around the first (שם) or the second (היסטוריה) section heading, all the body text letters become fuzzy, as if they are bold, but not quite. More like as if they are all written twice, one pixel to the left of the other.

Screenshot: https://he.wikipedia.org/wiki/%D7%A7%D7%95%D7%91%D7%A5:Bold_Letters_Screenshot.png

What should have happened instead?:
The appearance of the body text letters is not supposed to change.

Other information (browser name/version, screenshots, etc.):

I couldn't reproduce this on Legacy Vector, or on Firefox or on Linux. But Vector 2022 is the default on Hebrew Wikipedia and on many other languages, and Chrome on Windows 10 is one of the most common client combinations, so it's probably important.

QA steps

  1. Visit https://he.wikipedia.org/wiki/BTS using the latest version of Chrome on Windows and scroll to the end of the page
  2. Assert that the text is not rendered twice
  3. Visit https://en.wikipedia.org/wiki/The_Mousetrap using the latest version of Chrome on Windows and scroll to the end of the page
  4. Assert that the text is not rendered twice.
  5. Verify that the Table of contents is rendered correctly (no missing icons, text looks legible, section toggling works, etc)

QA Results - Prod

ACStatusDetails
1T322978#8567044
2T322978#8567044
3T322978#8567044

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Hi, this is happening also on French Wikipedia, logged-in users with Edge and Chrome (Vector 2022), a user says it happens when scrolling quickly.

Restricted Application changed the subtype of this task from "Bug Report" to "Spike". · View Herald TranscriptDec 5 2022, 6:31 PM
ovasileva renamed this task from letters become fuzzy after scrolling in some articles in Chrome in Vector 2022 to [SPIKE] letters become fuzzy after scrolling in some articles in Chrome in Vector 2022.Dec 5 2022, 6:31 PM
ovasileva removed Mabualruz as the assignee of this task.
ovasileva added a subscriber: Mabualruz.
LGoto set the point value for this task to 1.
ovasileva renamed this task from [SPIKE] letters become fuzzy after scrolling in some articles in Chrome in Vector 2022 to [SPIKE 4hrs] letters become fuzzy after scrolling in some articles in Chrome in Vector 2022.Dec 5 2022, 6:34 PM

I had a look at this using BrowserStack chrome on windows and was able to replicate it by visiting https://he.wikipedia.org/wiki/BTS. However, using https://he.wikipedia.org/wiki/BTS?safemode=1 made the issue disappear which suggests this might be related to a gadget

Confirmed by a French user: with ?safemode=1 the issue disappears for logged-in users. Without adding ?safemode=1, the issue is present when logged-in or logged-out so this is not related to a personal gadget activated intentionally by the user. The user actually doesn't see fuzzy letters with Firefox, but is experimenting it with Edge (logged-in and logged-out).

I was able to reproduce this fairly consistently on my setup on https://en.wikipedia.org/wiki/The_Mousetrap. When I got to the Characters section and scrolled slowly, Mollie and Giles didn't cause the behavior, but as soon as the top of Christopher Wren's line appeared, I got the blurred text. When I disabled the left-side contents and scrolled again, I didn't get that problem. Same behavior in both Chrome and Opera.

EDIT: Turns out this was dependent on my screen size. When I broke the tab out and made it significantly narrower, the fuzz happened much later. Default size was 1920x1080.

Here the same: logged in, Vector 2022, Opera 93.0.4585.37, Windows 11.

@ovasileva @Jdlrobson

I examined this issue today, and now I'm convinced it's a browser bug (likely affecting Blink-based browsers like Chrome and Opera on Windows) and it takes a certain combo of CSS and HTML to make it appear (JS has nothing to do with it). Here's what I discovered:

  1. I can only reproduce this bug on certain articles. Using Browserstack, I was able to see the bug anonymously using Chrome and Opera on https://en.wikipedia.org/wiki/The_Mousetrap?useskin=vector-2022 and https://he.wikipedia.org/wiki/BTS, but I can't see the bug on other articles. Barack Obama, Tree, and Cloud articles don't show it.
  2. It doesn't seem to have anything to do with JavaScript (including Gadgets). My initial thought was that it was related to gadgets, since appending the ?safemode=1 query param seems to eliminate the issue. However, I can replicate the issue with JavaScript turned off so I no longer believe that is the case.
  3. After much digging, I was eventually able to replicate the bug with Browserstack hitting my local server, using the MobileFrontendContentProvider extension, and visiting the /wiki/The_Mousetrap?useskin=vector-2022 page, but only after I included the following styles in my wiki/MediaWIki:Common.css page:
.infobox {
 background-color: #f8f9fa;
 float: right;
}

This somewhat explains why safemode=1 seems to fix this issue - safemode prevents MediaWiki:Common.css from loading and both enwiki and hewiki contain those styles in their MediaWiki:Common.css. Bizarrely, the bug only surfaces for me when both of those styles are present on pages like /wiki/The_Mousetrap. The styles themselves are benign, so it's most likely a browser issue that arises when certain conditions are met rather than something that needs to be fixed on our side.

Also FWIW, I tried to make a minimal test case that reproduces this bug and the following html file is what I have so far. It doesn't have any javascript or inline style tags in it. I think it can probably be stripped more with more time:

English wiki, logged in, Vector 2022, Opera 94.0.4606.54, Windows 11: Hide TOC avoids blurry fonts.

I would like to say this problem occurs when you scroll to a multibyte character, in the /wiki/The_Mousetrap case the problem is the word "cliché" below the "Twist ending and tradition of secrecy" title.

So any multibyte character will throw this glitch, it affects Hebrew, chinese, russian, and even spanish articles.

It seems like Wikipedia uses a custom font that does not have these characters included, so chrome tries to render it using an alternative font.

I have remove both occurrences of word cliché. Glitch remains.

ovasileva lowered the priority of this task from High to Medium.Jan 9 2023, 6:54 PM

English wiki, logged in, Vector 2022, Opera 94.0.4606.54, Windows 11: Hide TOC avoids blurry fonts.

Hiding the TOC seems to prevent the issue for me as well on the The_Mousetrap article. However, I think there may be other permutations involving CSS/HTML that prevent it. For example, if I simply remove the background-color from the infobox, the problem disappears for me:

https://jumpshare.com/v/q6qpdKFrXzXTj36HUL71

Although there are certain permutations of CSS/HTML that seem to trigger the issue, my guess is that this is primarily a regression that was introduced to the Blink rendering engine since version 107. Using Browserstack, I cannot reproduce the issue in Chrome versions 101 - 106. It is only Chrome 107+ that I've been able to reproduce.

This issue seems related to the following bug reports involving Chromium:

Moving this to signoff as I think this is a Blink rendering engine issue. Furthermore, it seems the Chromium team is working on a fix based on their latest comment in their bug report for this issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=1363981#c53

Untagging from the board but will keep monitoring as the Chromium team works on this.

think there's a good chance that my patch for T327460 (https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/881744) might also fix this issue, although I'm not sure since I couldn't reproduce it on my device.

@SarekOfVulcan @nray (and anyone else who can reproduce): Could you try out if that fix works for you?

  1. Please check if the issue doesn't occur on https://patchdemo.wmflabs.org/wikis/3d569ad0e7/wiki/The_Mousetrap?useskin=vector-2022
  2. Please check if the issue still occurs on https://patchdemo.wmflabs.org/wikis/8114fc544a/wiki/The_Mousetrap?useskin=vector-2022 (this is to ensure that it's actually my change causing the difference, and not some other divergence in configuration between Wikipedia and this testing wiki)

The steps to reproduce in the OP doesn't cause the bug for me. Windows, Google Chrome.

I am getting the below issue though, very intermittently. Is this the same bug?

vector-2010 I think

image.png (820×1 px, 373 KB)

image.png (780×1 px, 411 KB)

image.png (939×1 px, 193 KB)

matmarex:

  1. can't reproduce bug
  2. can reproduce bug

Good work.

ovasileva raised the priority of this task from Medium to High.Jan 23 2023, 7:56 PM

Thanks @matmarex for the workaround! I've merged the patch and am planning to backport it tomorrow

Thanks @matmarex, wasn't sure what to look for. Same result for me, 1 seems to fix it, 2 reproduces it.

The workaround has now been deployed everywhere so, in theory, this problem should be bypassed for the time being. Thanks again to @matmarex for the deeper investigation and patch!

nray updated the task description. (Show Details)
nray updated the task description. (Show Details)
Edtadros subscribed.

Test Result - Prod

Status: ✅ PASS
Environment: enwiki, hewiki
OS: macOS Ventura
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

Visit https://he.wikipedia.org/wiki/BTS using the latest version of Chrome on Windows and scroll to the end of the page
✅ AC1: Assert that the text is not rendered twice

Screenshot 2023-01-28 at 6.13.05 PM.png (1×2 px, 1004 KB)

Visit https://en.wikipedia.org/wiki/The_Mousetrap using the latest version of Chrome on Windows and scroll to the end of the page
✅ AC2: Assert that the text is not rendered twice.

Screenshot 2023-01-28 at 6.17.14 PM.png (1×2 px, 1 MB)

✅ AC3: Verify that the Table of contents is rendered correctly (no missing icons, text looks legible, section toggling works, etc)

Screen Recording 2023-01-28 at 6.14.41 PM.mov.gif (994×1 px, 700 KB)

Screen Recording 2023-01-28 at 6.19.02 PM.mov.gif (994×1 px, 778 KB)

Looks good, resolving. Thanks for figuring this one out @nray, @matmarex!

Unfortunately, I can still reproduce this on Chrome on Linux when scrolling in https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements

@Nikerabbit I think you're the first person experiencing this on Linux. This may be a separate issue. Can you file a new task with more details and screenshots?

Why do you think it's a different issue? The upstream issue https://bugs.chromium.org/p/chromium/issues/detail?id=1363981 is marked for both Linux and Windows and symptoms are the same. I'll take a screenshot when it happens again (of course, the issue goes away when I complain):

Update from upstream: "The bug has probably been fixed in M111"
So if you run Chrome Canary or dev build, this should no longer be an issue.... according to the schedule https://chromestatus.com/roadmap that should be stable (at the latest) on 1 March.

Looks like this one is finally ready to resolve