rust-lang.org and crate documentation pages require "fira" font

[rnd42]

I've actually had this problem for a while now but just decided to troubleshoot it. So here's what I was initially seeing:

Then i found and disabled a single CSS rule and got this:

I would file this issue with the rust-lang/rust-www repository but then I had the same problem with viewing documentation pages from 3rd-party crates hosted on Github so I'm assuming it's Rust's documentation generator itself that is generating this CSS rule. I have installed the "fira" font from the ArchLinux AUR and no longer have to disable the CSS rule, but there really should be a fall-back font set. In case it's relevant I'm running ArchLinux x86_64, Gnome 3.14.2 and Firefox 33.1.1.

[tomjakubowski]

That's very odd, because there are several fallback fonts, including the fallback of fallbacks sans-serif, and Fira Sans should be loaded as a @font-face font. If Fira fails to load for whatever reason (including if you have disabled @font-face in your browser or with an extension), sans-serif as a fallback should still show something reasonable.

[adam-frisby]

I don't think this is a problem with the fallback. What your first screenshot looks like is what the page looks like in Firefox before the fonts download.

What might be useful is the "Network" tab and make sure to do a hard refresh (Ctrl + F5)

(Although it might not attempt to download the font at all now you have it installed)

[rnd42]

I agree that the CSS rule seems like it should work fine. I uninstalled "Fira" to troubleshoot this further. You mentioned that the font should be downloaded which made me realize I should check NoScript, but it doesn't show any blocked resources... So just to be extra safe I disabled ALL extensions but I'm still getting invisible text. So here is a screen shot of my "Network" tab with all extensions disabled after a hard refresh:

Just to be thorough I tried this from Google Chrome but that displays the page without text as well. I even tried changing my GTK+ and Firefox themes in case it was just inheriting some white text rule from there, but it didn't have any effect. Just incase you want an example of 3rd-party documentation with similar issues here's a screenshot from https://hyperium.github.io/hyper/hyper/index.html with the networking tab open (Note that the SourceSerifPro-Regular font seems to download and display fine):

And with the CSS rule mentioning "Fira" disabled:

[steveklabnik]

This has been a persistent problem in Chrome, I know there were some previous tickets about it. Havne't been able to diagnose a root cause :/

[mahkoh]

The root cause is that simply using the system fonts isn't considered webscale enough for a hip language such as rust.

[steveklabnik]

Not helpful.

[tomjakubowski]

@steveklabnik do you know if this has been a persistent problem in Firefox as well? Looks like @rnd42 sees it in both Chrome and Firefox.

[MatejLach]

I can confirm this problem in Chrome as well as Firefox when I don't have the Fira Sans fonts installed.
Also, I don't have @font-face disabled.
I think the bigger problem arising from this is that rustdoc documentation won't show up properly without having these fonts, making rustdoc somewhat problematic within intranets etc.
Funnily enough, on mobile Chrome (Android 5.0), it works fine, which would suggest that the mobile CSS is written correctly, because Android doesn't have Fira Sans and so the fallback kicks in as it should.
Maybe comparing the mobile/desktop css in the relevant sections will provide some leads.

[tomjakubowski]

As another data point I don't have any Fira fonts installed on either of my Arch Linux boxes and the font loads and page renders fine for me in both Firefox 31 and Chromium 39.

[steveklabnik]

@tomjakubowski I was pretty sure it was just Chrome, but I didn't see that someone also reported a Firefox.

I use Firefox with basically no fonts installed and it works just fine on Debian Jessie.

[steveklabnik]

@MatejLach I still believe this has something to do with a corrupted local font install, which the browser doesn't realize is corrupted. I could be wrong, though.

[MatejLach]

@steveklabnik I don't know about the corrupted fonts thing, since for me it happens consistently across 2 arch machines and only on rust-lang.org, which would suggest that the problem isn't on my side, although I could not verify it 100%.

[steveklabnik]

Ahhh interesting.

[tomjakubowski]

@tomjakubowski I was pretty sure it was just Chrome, but I didn't see that someone also reported a Firefox.

That was reported in the OP of this issue 😄

[adrientetar]

Funnily enough, on mobile Chrome (Android 5.0), it works fine, which would suggest that the mobile CSS is written correctly, because Android doesn't have Fira Sans and so the fallback kicks in as it should.

• The same CSS is used regardless of the client afaict.
• It works for me under Ubuntu and Windows (7, 8.1).

Can you specify on which OS (or distro) you are

[MatejLach]

@adrientetar On my desktop and laptop I use Arch x64, which isn't saying much since Arch doesn't come with any fonts preinstalled, so I guess simply not having the proper fallback fonts installed is the issue here, since installing Fira Sans resolves it, I guess it's not a big deal in the end, although it is a bit strange that so far rust-lang.org is the only site where I observe this problem (and of course in rustdoc by extension).

[adrientetar]

@MatejLach sans-serif at the end of the font stack means that the browser should use the default sans-serif font. This will work on any browser so clearly there is an issue with arch.
Talking about Firefox, it should stop trying to use the webfont and switch to fallback if it does not load within 3 seconds after the concurrent rendering steps are done. Clearly there is an issue going on here that is specific to Arch.

[MatejLach]

@adrientetar Most likely, this is indeed specific to Arch, because I have dozen sans-serif fonts from the Google Web Fonts directory installed, I just can't think of as to why the problem would actually occur with Arch.
May need to ask around.

[arslan]

I had a similar problem (July 2014) and solved it. (rust-lang/prev.rust-lang.org/issues/51). I will quote the solution here: "The problem was caused by the font that was already installed on my system as part of google fonts stack, which happens to bear the same name as the font that was supposed to be downloaded from the website. After deleting it from my system all browsers started sending request for the font from the website, which solved the problem."

[rnd42]

Thank you rcx, that's exactly the problem I had. I did the following to fix it:

$ mkdir ~/temp

remove the Fira fonts installed from the ttf-google-fonts-git package:

$ sudo mv /usr/share/fonts/TTF/Fira* ~/temp/

If you installed the Fira font packages via yaourt to fix this you can now uninstall them:

$ yaourt -R otf-fira-mono otf-fira-sans

and now I can view the site fine.

[adrientetar]

We call local fonts first in the CSS. Would removing that call a good thing? Assuming other people affected also run Arch?

[adrientetar]

(I still believe that there is a bug which should be reported to Arch maintainers.)

[MatejLach]

@adrientetar I would report it, expect that I am not sure which part of the font stack this bug touches.
Also, stuff like the Google Web Fonts isn't maintained in the official repos, but in AUR, which is user-maintained

[rnd42]

I added a comment to a preexisting issue at https://code.google.com/p/googlefontdirectory/issues/detail?id=368 . Thanks for your help.