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.

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.

In T322978#8506429, @Grimes2 wrote:

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:

• https://bugs.chromium.org/p/chromium/issues/detail?id=1363981&q=text%20rendering%20twice&can=2
• https://support.google.com/chrome/thread/179089685

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

matmarex:

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

Good work.

Same.

1. Can't reproduce
2. Can reproduce

Same. 1 Can't, 2 Can. Thanks!

I've seen 3 reliable reports of this happening on Chrome. This is a link to the thread (including a screenshot): https://www.reddit.com/r/wikipedia/comments/10gcp3h/text_darkness_buggy_in_new_wikipedia_format/j5ch2u4/?context=3

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!

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

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