User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170725113540 Steps to reproduce: Go to https://github.com/mozilla Fedora 26 Latest Nightly from Flatpack Font: Default, DejaVu Serif Actual results: See screenshot. Can't see the text on the page and can't click on repositories Expected results: I should see text and buttons.

Please upgrade your graphics driver: https://support.mozilla.org/kb/upgrade-graphics-drivers-use-hardware-acceleration

(In reply to Kohei Yoshino [:kohei] from comment #1) > Please upgrade your graphics driver: > https://support.mozilla.org/kb/upgrade-graphics-drivers-use-hardware- > acceleration We don't use acceleration on Linux, so that's unlikely to help.. Nical, ever seen anything like this on Fedora?

(In reply to Bas Schouten (:bas.schouten) from comment #2) > (In reply to Kohei Yoshino [:kohei] from comment #1) > > Please upgrade your graphics driver: > > https://support.mozilla.org/kb/upgrade-graphics-drivers-use-hardware- > > acceleration > > We don't use acceleration on Linux, so that's unlikely to help.. > > Nical, ever seen anything like this on Fedora? Yeap (and my system is pretty up-to-date). If you want, if I have time this week-end, I can build firefox from sources and investigate the output.

Oh. I just retried. And I removed the font-family attribute (for twitter it's ""Helvetica Neue",Helvetica,Arial,sans-serif" on body and for github "-apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"". And now, I can see the text.

The font appears to not be loaded properly. It's not just rendering because the size of some of the boxes that should contain text is changed (like the tags on the github issues) so at the layout stage we already have a problem. Lee you know more about fonts than I do, does this ring any bell? This appears to be the same as bug 1390390 and bug 1391246.

Jonathan, maybe probably knows more about the font loading business.

(In reply to Sébastien Blin [:sblin] [:amarok] from comment #4) > Oh. > > I just retried. And I removed the font-family attribute (for twitter it's > ""Helvetica Neue",Helvetica,Arial,sans-serif" on body and for github > "-apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, > sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"". And > now, I can see the text. I notice in both cases there is "Helvetica" in the font-family list. Does just removing that fix things? Or inserting an available font name such as "DejaVu Sans" (presumably) at the *start* of the list, so it will be used in preference to Helvetica? I'm wondering if you have a Helvetica font, or a substitution set up in fontconfig, that for some reason is failing. What does fontconfig show if you run fc-match :family=Helvetica in a terminal?

(In reply to Jonathan Kew (:jfkthame) from comment #7) > (In reply to Sébastien Blin [:sblin] [:amarok] from comment #4) > > Oh. > > > > I just retried. And I removed the font-family attribute (for twitter it's > > ""Helvetica Neue",Helvetica,Arial,sans-serif" on body and for github > > "-apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, > > sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"". And > > now, I can see the text. > > I notice in both cases there is "Helvetica" in the font-family list. Does > just removing that fix things? Or inserting an available font name such as > "DejaVu Sans" (presumably) at the *start* of the list, so it will be used in > preference to Helvetica? > > I'm wondering if you have a Helvetica font, or a substitution set up in > fontconfig, that for some reason is failing. What does fontconfig show if > you run > > fc-match :family=Helvetica > > in a terminal? Yeah, if I enter Deja Vu, it works. ``` fc-match :family=Helvetica texgyreheros-regular.otf: "TeX Gyre Heros" "Regular" ```

Interesting.... where is the texgyreheros-regular.otf file installed? I'm wondering if this might be a sandboxing issue. If you set security.sandbox.content.level to 1 in about:config (default on Nightly is 3, I believe), and restart the browser, does that make any difference?

/usr/share/texlive/texmf-dist/fonts/opentype/public/tex-gyre/texgyreheros-regular.otf And yes it's a sanboxing issue because I test the nightly without flatpak and it works.

(In reply to Sébastien Blin [:sblin] [:amarok] from comment #10) > /usr/share/texlive/texmf-dist/fonts/opentype/public/tex-gyre/texgyreheros- > regular.otf > > And yes it's a sanboxing issue because I test the nightly without flatpak > and it works. Aha... I think that means the flatpak sandbox is blocking Firefox from accessing the font file. You should report this to whoever is creating/maintaining the flatpak distribution. Actually, a quick search turns up https://github.com/xhorak/firefox-devedition-flatpak/issues/36, which sounds very much like your issue.

The comments there suggest that adding /run/host/fonts/ to security.sandbox.content.read_path_whitelist may be a solution. If this is a widespread issue, perhaps that should be included in the default settings.

gcp: See comments above, and the linked Github flatpak issue. Should we do anything about this in mozilla, e.g. by adding the required path(s) in SandboxBrokerPolicyFactory.cpp, or should this be left as something for the packager/distro to address via the whitelist pref?

I can reproduce this bug on Ubuntu 17.04, with Flatpak 0.8.5-1, using org.mozilla.FirefoxNightly from https://firefox-flatpak.mojefedora.cz/; the About box reports its version as "57.0a1 (2017-09-12) (64-bit)". I added "/run/host/fonts/" to security.sandbox.content.read_path_whitelist in about:config (this value was previously empty) and restarted Firefox, and I no longer see the bug.

(In reply to Jonathan Kew (:jfkthame) from comment #12) > The comments there suggest that adding /run/host/fonts/ to > security.sandbox.content.read_path_whitelist may be a solution. If this is a > widespread issue, perhaps that should be included in the default settings. Yes, let's do that. We have the prefs so the distros can customize what they need if they put stuff in "odd" places, but for the initial rollout let's be proactive and cover things that we can.