Monospace font in Browser Chrome

Confirming this bug in 11.0.1 running on Lubuntu 18.04.6 LTS

added Bug label

This issue affects me too, with the Tor Browser installed on Kubuntu 20.04.3 LTS. All the text associated with the browser UI (e.g. dialog boxes, menus, toolbars, etc.) are displayed in a monospaced font. Deleting the existing Tor directory, downloading the Tor Browser, and extracting it from its archive didn't fix the issue.

I have several Linux distros installed, and, curiously, this issue only shows up on Kubuntu. The others (KDE neon, Debian Stable with KDE, Linux Mint Cinnamon) use a sans-serif font as expected.

Hi, is the Linux Mint Cinnamon you tried based on Ubuntu, or on Debian?

Because I tried with Ubuntu, Lubuntu, and then with a minimal Ubuntu created with debootstrap and all of them failed.

mentioned in issue #40703 (moved)

mentioned in issue tor-browser-build#40387 (closed)

A comment from a forum user on the TB 11.0.1 thread:

I noticed the problem goes away if I set gfx.e10s.font-list.shared to true in about:config and quit and re-start the browser.

Edit to add information: My platform is a VM with Ubuntu 21.10 and XFCE. I have disabled hardware acceleration in settings and the VM does not have a GPU or llvmpipe. The problem does not appear with 10.5.10. The only .ttf files outside of the Tor Browser directory are DejaVuSans-Bold.ttf, DejaVuSans.ttf, DejaVuSansMono-Bold.ttf, DejaVuSerif-Bold.ttf, DejaVuSansMono.ttf, DejaVuSerif.ttf. The browser dev tools say that the monospaced font on the browser chrome is Cousine which must have come from Tor Brower’s bundled fonts.

Hey thanks, that worked.

(In my case the Tor Browser was using the same monospaced font that was set for the system, i.e. Liberation Mono. I don't know what the "gfx.e10s.font-list.shared" setting does, but thank you for the fix!)

changed milestone to %Tor Browser: 11.0 Issues with previous release

https://bugzilla.mozilla.org/show_bug.cgi?id=1723468

https://bugzilla.mozilla.org/show_bug.cgi?id=1723468

Thanks. So it looks like setting gfx.e10s.font-list.shared to true is not a good solution.

I found this issue is somehow related to the following font files:

Cousine-Regular.ttf
NotoSansBengali-Regular.ttf
NotoSansCanadianAboriginal-Regular.ttf
NotoSansCherokee-Regular.ttf
NotoSansKannada-Regular.ttf
NotoSansThaana-Regular.ttf

I believe Cousine is the font triggering the monospace issue, but the NotoSans fonts are trigger (what looks like) tor-browser-build#40387 (closed).

Did anyone hear back from Jonathan? I haven't. He's always replied on bugzilla with FF bugs. "Something seems to be happening with tff fonts, namely some NotoSans ones, causing fallback issues" was my summary for both bugs

Thorin (@thorin):

Thorin commented on a discussion: #40685 (comment 2765091)

Did anyone hear back from Jonathan? I haven't. He's always replied on bugzilla with FF bugs. "Something seems to be happening with tff fonts, namely some NotoSans ones, causing fallback issues" was my summary for both bugs

Nope.

@gk he's got 88 ni's :-( but is definitely active - maybe gmail wasn't the best way to contact him, might be easier if someone with some clout creates an upstream bug (although I do get that it's not an upstream issue)?

Thorin (@thorin):

Thorin commented on a discussion: #40685 (comment 2765107)

@gk he's got 88 ni's :-( but is definitely active - maybe gmail wasn't the best way to contact him, might be easier if someone with some clout creates an upstream bug (although I do get that it's not an upstream issue)?

Yeah, that's an option. We are investigating the font issues a bit this week/next week. If we think there is actually an upstream issue involved we'll file a ticket at bugzilla.

It looks like Tor Browser does not like Arimo at all.

I tried to keep only Arimo-Regular.ttf and only one other font (any font, as long as it was only Arimo + the other one). TB always picked up the other one. I also tried with Comic Sans and it is still preferred to Arimo .

Eventually, Cousine is one of the fonts that is picked the most. It is preferred even to Roboto and Bitstream Vera.

The most strange behavior is that fc-match does match with Arimo, instead. Anyway, I have been creating some logs, but I will have a better look at them tomorrow.

To do so, I forked and recompiled fontconfig, because the logs were all messed up, between processes and missing synchronization of threads. So I have the same binaries in Debian and in Ubuntu. But while Debian works completely fine, Ubuntu has the problem. And it seems unrelated to the desktop environment. But also unrelated to system configuration, because only ours is picked up.

In any case, this is definitely related to tor-browser-build#40387 (closed), in my opinion...

I think Arimo always lost to the other fonts you tried because the other ones were last in alphabetical order. I have managed to avoid the interleaving of FC_DEBUG logs by disabling auto-connect to tor and changing the number of content processes to 1.

Another thing to try is --MOZ_LOG=fontlist:5. With only Arimo and Cousine in the fonts dir, it will report the parent process loads only Cousine, whereas the child processes load both Arimo and Cousine. The many checks for XRE_IsParentProcess() in gfxPlatformFontList.cpp and gfxFcPlatformFontList.cpp may be a clue, although I could not follow the code well enough to find the culprit. If you are able to recompile the browser, I think these would be great places to add more logging.

Thanks, will try!

I thought it was alphabetical order as well, but Cousine is preferred to Roboto...

I separated the logs of the various processes in fontconfig by hardcoding a path in the source, and writing to a file that contained the PID in its name...

mentioned in issue tor-browser-build#40382 (closed)

Found the culprit, finally: it is FontVisibility gfxFcPlatformFontList::GetVisibilityForFamily(const nsACString& aName) (gfx/thebes/gfxFcPlatformFontList.cpp).

We had the problems in Fedora and Ubuntu because the function is checking the whitelist, and reporting anything is included in Tor Browser but not in the system as FontVisibility::User.

Since we do ship our fonts, we should return either create our own list, and return FontVisibility::Base or simply return FontVisibility::Unknown. In the former case, doing so in code may be preferable, as we could leave the preference of creating any whitelist to users (if they know what they do, and know that modifying that value can be used for fingerprinting).

For Ubuntu and Fedora, eventually the first font of a hash table was chosen. Probably, removing fonts changed their order in the hashtable.

Nice work. We can follow a pattern we use in other Tor Browser patches where we add #ifndef TOR_BROWSER_VERSION around the Ubuntu and Fedora special cases. This will give us consistent behavior on all distros.

This is an interesting case where Mozilla is trying to provide fingerprinting resistance, but it doesn't quite fit our needs.

Every call to GetVisibilityForFamily is in the form of

FontVisibility visibility = aAppFonts ? FontVisibility::Base : GetVisibilityForFamily(keyName);

Bundled fonts are loaded with aAppFonts as true and so GetVisibilityForFontFamily will never be called for bundled fonts.

It's not a misconfiguration, it's a bug. Otherwise it wouldn't only affect the browser chrome. about:tor renders properly with the bundled fonts because the content processes avoid the bug somehow. You can see this with the experiment I mentioned here. With only Arimo and Cousine in the fonts directory, the parent process logs only mention Cousine and the child process logs mention Cousine and Arimo.

Look at this code and note the different values for aAppFonts between fonts looked up from (presumably) fonts.conf with FcSetSystem and from the bundled fonts dir (u"fonts"_ns in the second code block) with FcSetApplication.

gfxFcPlatformFontList.cpp starting at line 1527

  // iterate over available fonts
  FcFontSet* systemFonts = FcConfigGetFonts(nullptr, FcSetSystem);
  AddFontSetFamilies(systemFonts, policy.get(), /* aAppFonts = */ false);

#ifdef MOZ_BUNDLED_FONTS
  if (StaticPrefs::gfx_bundled_fonts_activate_AtStartup() != 0) {
    FcFontSet* appFonts = FcConfigGetFonts(nullptr, FcSetApplication);
    AddFontSetFamilies(appFonts, policy.get(), /* aAppFonts = */ true)**;
  }
#endif

gfxFcPlatformFontList.cpp starting at line 2573

#ifdef MOZ_BUNDLED_FONTS
void gfxFcPlatformFontList::ActivateBundledFonts() {
  if (!mBundledFontsInitialized) {
    mBundledFontsInitialized = true;
    nsCOMPtr<nsIFile> localDir;
    nsresult rv = NS_GetSpecialDirectory(NS_GRE_DIR, getter_AddRefs(localDir));
    if (NS_FAILED(rv)) {
      return;
    }
    if (NS_FAILED(localDir->Append(u"fonts"_ns))) {
      return;
    }
    bool isDir;
    if (NS_FAILED(localDir->IsDirectory(&isDir)) || !isDir) {
      return;
    }
    if (NS_FAILED(localDir->GetNativePath(mBundledFontsPath))) {
      return;
    }
  }
  if (!mBundledFontsPath.IsEmpty()) {
    FcConfigAppFontAddDir(nullptr, ToFcChar8Ptr(mBundledFontsPath.get()));
  }
}
#endif

Hey @torgitlab11235, of course it is a bug. And your comments helped me tracking it.

One special thing that only the main process of Firefox does is looking for changes in fontconfig. It sets a timer and then queries fontconfig if the configuration changed.

If it did, it reloads the font configuration. At the end of the process, gfxPlatformFontList::GetDefaultFont (gfx/thebes/gfxPlatformFontList.cpp) is called.

The first line of the function is FontFamily family = GetDefaultFontForPlatform(aStyle);. On Debian, where everything works, this family is Arimo, and it is returned. (I say Debian because it has been my distro for many years, but almost all distros work as intended).

On Ubuntu, on the other hand, family is null! Same on Fedora. So, the function returns mFontFamilies.ConstIter().Data(), instead. mFontFamilies is a hash table, so I assumed this is like doing *map.begin() on a std::unordered_map. I did not really check that, but if it is, the first element does not have a semantic reason to be the first.

In any case, the problem is that GetDefaultFontForPlatform returned null. So, why does this happen? Let's have a look at it. Or, better, to gfxFcPlatformFontList::FindGenericFamilies.

Inside the lambda, you can see that a font is added to prefFonts only if gfxPlatformFontList::FindAndAddFamilies returns true. In Ubuntu and Fedora, this always returns false, because each call is stopped at the first if, where gfxPlatformFontList::IsVisibleToCSS is called. Here you can see where visibility really has its role: aFamily.Visibility() <= mVisibilityLevel || IsFontFamilyWhitelistActive();.

mVisibilityLevel is set to Base, when resistfingerprinting is true (which has been added between Firefox 78 and Firefox 91 @sysrqb), see gfxPlatformFontList::SetVisibilityLevel(). The problem is then that aFamily.Visibility() returns something different in Fedora and Ubuntu, wrt other Linux distributions. And this happens because Mozilla ships a list of fonts that Fedora and Ubuntu install by default, as you said (gfx/thebes/StandardFonts-linux.inc). However, they do not apply to Tor Browser, because it is configured to ignore the system fonts. So, these lists should be ignored as well, even when running on Fedora/Ubuntu.

This will be my patch. I already wrote it yesterday evening, but for some reason the build failed, in it was already late, so I did not check the errors. I will continue Monday.

Also, you said something about bundled fonts. Well, they are bundled, but they are seen as system fonts, thanks to the <dir>fonts</dir> in fonts.conf. So, GetVisibilityForFamily is called, but it returns the wrong result (try with a debugger ).

The fix for Firefox bug 1661532 has regressed, check the latest comments. To me this means that bundled fonts are definitely supposed to take precedence and be visible, and that this is a bug in upstream Firefox.

The bug was fixed in September 2020 and in April 2021 thehim reported that the bug was back. Looking at the before and after for gfxPlatformFontList and gfxFcPlatformFontList a big change was deferred cmap loading. Is that the timer you're referring to? Fontconfig isn't changing so it shouldn't matter if fontconfig is on a timer.

On Ubuntu, on the other hand, family is null!

It's a FontFamily from gfx/thebes/gfxFontEntry.h where bool IsNull() const { return mIsShared ? !mShared : !mUnshared; } returns true;

Also, you said something about bundled fonts. Well, they are bundled, but they are seen as system fonts, thanks to the <dir>fonts</dir> in fonts.conf.

So remove that line in fonts.conf instead of diverging TorBrowser from upstream Firefox code. No matter whether they are configured as system fonts they are definitely also bundled as you can see in the code for gfxFcPlatformFontList::ActivateBundledFonts() that I included in my last reply.

I am looking at the bug you pointed out. Thanks for reporting the link.

instead of diverging TorBrowser from upstream Firefox code

I am not really comfortable on seeing code that is enabled on distro basis. However GetDistroID is called only in gfxFcPlatformFontList::GetVisibilityForFamily. So, if we fix the upstream bug we might keep it, after all. I am going to ask more experienced devs later .

Is that the timer you're referring to? Fontconfig isn't changing so it shouldn't matter if fontconfig is on a timer.

No, I was referring to a timer as the possible reason for which you have a lots of output for the same fonts in the main process when enabling FC_DEBUG=....

Also, that timer was useful for me to add a breakpoint for debug, so I thought it was a useful information to know.

It's a FontFamily from gfx/thebes/gfxFontEntry.h where bool IsNull() const { return mIsShared ? !mShared : !mUnshared; } returns true;

Of course, and if you go to gfxFcPlatformFontList::GetDefaultFontForPlatform you see that it is null because it is default-constructed. The whole point was FindGenericFamilies failing on Ubuntu and Fedora, not the family telling that it is null.

mentioned in merge request !236 (closed)

assigned to @pierov

added Doing label

mentioned in issue tor-browser-build#40399 (closed)

Alright, I cherry-picked the fix that landed on mozilla-central onto tor-browser-91.4.0esr-11.5-1 (6ebf4b5c). It applied cleanly and we should be good here until we get an esr91 backport, closing.

closed

tor-browser-build#40382 (closed) + #40685 (closed) =

Should I open a new Issue?

Hi, you are using Tor Browser 11.0.2, which is the current stable.

However, the bug has been fixed on 11.5 (but not on the alpha, only on the nighlies), and we backported it to 11.0.3. So, please wait for this release, and then please let us know if the problem persists.

Thanks .

mentioned in merge request tor-browser-build!386 (merged)

Mozilla's fix got backported to tor-browser-91.4.1esr-11.0-1 (093426b4).

mentioned in commit tor-browser-build@bb28297a

marked this issue as related to #40966 (closed)

Monospace font in Browser Chrome

Designs

Child items 0

Activity