Backticks are not rendered as inline characters in textarea

[alexPMobal]

Describe the bug
Backtick characters are not rendered as inline characters inside of textarea. This makes formatting snippets a painful experience.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

Desktop (please complete the following information):

• OS: Ubuntu 24.04.1 LTS
• Browser: chrome
• Version 131.0.6778.139 (Official Build) (64-bit)

Additional context

The issue seem to be related to "Noto Sans" being used as a font family, removing it solves the issue.

[camertron]

Hey @alexPMobal, thanks for bringing this up! Unfortunately I was not able to reproduce the issue on Ubuntu under either Chrome or Firefox. Have you considered upgrading to Ubuntu 24.10 to see if that fixes things?

[alexPMobal]

@camertron thanks for the suggestion. I haven't but I will try!
The issue doesn't occur in Firefox for me too. But it seem to be a known problem with Noto fonts. A quick search reveals there are a bunch of reports for this issue throughout the years, including different systems

[alexPMobal]

Updating to Ubuntu 24.10 didn't solved the issue for Chrome (same version ,131.0.6778.139 (Official Build) (64-bit))

[camertron]

Alright, so this definitely is/was an issue with certain versions of the Noto Sans font, eg: notofonts/noto-fonts#736

It looks like we actually tried to fix it a few years ago (internal-only link): https://github.com/github/primer/issues/1531

Here's the resulting CSS fix (internal-only link): https://github.com/github/github/blob/fb8ed61a2187f1b62410e455725e9b64522f1dcc/app/assets/stylesheets/bundles/global/hx_browsers.scss#L76-L89

I'm looking into why this isn't working anymore. Perhaps we just need to update our version of Noto Sans 🤔

[camertron]

Perhaps we just need to update our version of Noto Sans 🤔

Through a conversation with a co-worker, I have come to understand that we don't actually serve a copy of Noto Sans to customers - it's just part of our font stack. In other words, we use whatever version is currently installed on the host system.

@alexPMobal in light of this, could you try upgrading the version of Noto Sans you have installed on your system?

[alexPMobal]

I tried reinstalling and upgrading fonts-noto package, as well as installing the font from Google fonts. Doesn't seem to have an effect for me.
The links in Noto Fonts' ticket (this one and this one) do look normal interestingly.

[camertron]

@alexPMobal I just downloaded the fonts-noto package and did a little font forensics. It looks like the fonts included in that package are all ~5 years old. You might have better luck downloading and installing from the most recent release on GitHub, eg: https://github.com/notofonts/latin-greek-cyrillic/releases/tag/NotoSerif-v2.015

Unfortunately there's not much more I can do here, since we don't actually host the font file.

[alexPMobal]

the naming conversion on the package does look 5 years old, but the release time is 2024-10-17, which seem to be ~the same as the package on their github :) I'll try it though, haven't tried it yet

[alexPMobal]

since we don't actually host the font file.

This made me wonder why then font is rendered differently on chrome and firefox, and I checked where it comes from for chrome. Turns out one of extensions was providing it, and it was the broken version 🤦‍♂️ disabling it solves the issue. Should've checked before 😆

Thanks for the help!

[camertron]

Oh wow nice find, thanks for reporting back!

the naming conversion on the package does look 5 years old, but the release time is 2024-10-17, which seem to be ~the same as the package on their github

Not that it matters now, but I actually opened up a number of the font files and read their release date from the header table. That's how I determined they were a bit old.