Since a few days, Nightly renders Liberation & Ubuntu fonts (for Helvetica, Arial, Ubuntu) as being either empty or squares (for any string larger than ~32 characters?). I can reproduce this issue on: - about:newtab - google.com - docs.google.com - github.com - … Which makes this issue quite painful. In the mean time I have to stay on an old version of Nightly, or edit every page with the dev-tools. bad: https://hg.mozilla.org/mozilla-central/rev/36f95aeb4c77f7cf3b3366583008cd6e4b6b1dba good: https://hg.mozilla.org/mozilla-central/rev/131e19a573e901fb4d01b471b11b7916420b9fee

You can see the issue on github & devtools: https://drive.google.com/file/d/0B0XdfV25b2n5XzFhT2lGODRvZUU/view?usp=sharing

Possibly related to bug 1379895? Can you narrow things down with mozregression?

Compiling locally gives me the following assertion: > ASSERTION: Failed to make scaled font: 'cairo_scaled_font_status(scaledFont) == CAIRO_STATUS_SUCCESS' I will try to bisect next week, if the problem still exists.

Using rr to investigate from where the CAIRO_STATUS_NO_MEMORY error came from, suggests that we never initialized the memory for scaled_font->status. (rr) p scaled_font->status $2 = CAIRO_STATUS_NO_MEMORY (rr) watch -l scaled_font->status Hardware watchpoint 2: -location scaled_font->status (rr) rc Continuing. Thread 1 hit Hardware watchpoint 2: -location scaled_font->status Old value = CAIRO_STATUS_NO_MEMORY New value = <unreadable> 0x00007f63320745a5 in _raw_syscall () from /nix/store/rn9vv9qdw2l5vvy5d9fxbv04w25q930a-rr-4.5.0-master/bin/../lib/rr/librrpreload.so (rr) bt #0 0x00007f63320745a5 in _raw_syscall () at /nix/store/rn9vv9qdw2l5vvy5d9fxbv04w25q930a-rr-4.5.0-master/bin/../lib/rr/librrpreload.so […] #15 0x00007f6331c4eff1 in dlopen@@GLIBC_2.2.5 () at /nix/store/63gvnrj4z154kpyjpskl6s0hwmyx9x0w-glibc-2.25/lib/libdl.so.2 #16 0x000000000041c067 in GetLibHandle (aDependentLib=0x7ffc67c77710 "/home/nicolas/mozilla/_build/firefox/bugzil.la/js-startup-cache/final/x64/clang/dbg/dist/bin/libxul.so") at /home/nicolas/mozilla/contrib-push/xpcom/glue/standalone/nsXPCOMGlue.cpp:105 #17 0x000000000041c067 in ReadDependentCB (aDependentLib=0x7ffc67c77710 "/home/nicolas/mozilla/_build/firefox/bugzil.la/js-startup-cache/final/x64/clang/dbg/dist/bin/libxul.so") at /home/nicolas/mozilla/contrib-push/xpcom/glue/standalone/nsXPCOMGlue.cpp:157 #18 0x000000000041c067 in XPCOMGlueLoad(char const*) (aXPCOMFile=aXPCOMFile@entry=0xf1dc90 "/home/nicolas/mozilla/_build/firefox/bugzil.la/js-startup-cache/final/x64/clang/dbg/dist/bin/libxul.so") at /home/nicolas/mozilla/contrib-push/xpcom/glue/standalone/nsXPCOMGlue.cpp:333 #19 0x000000000041c207 in mozilla::GetBootstrap(char const*) (aXPCOMFile=0xf1dc20 "/home/nicolas/mozilla/_build/firefox/bugzil.la/js-startup-cache/final/x64/clang/dbg/dist/bin/firefox") at /home/nicolas/mozilla/contrib-push/xpcom/glue/standalone/nsXPCOMGlue.cpp:408 #20 0x00000000004061fa in InitXPCOMGlue(char const*) (argv0=<optimized out>) at /home/nicolas/mozilla/contrib-push/browser/app/nsBrowserApp.cpp:248 #21 0x0000000000405a8f in main(int, char**, char**) (argc=16, argv=0x7ffc67c798e8, envp=0x7ffc67c79970) at /home/nicolas/mozilla/contrib-push/browser/app/nsBrowserApp.cpp:280

(In reply to Jonathan Kew (:jfkthame) from comment #3) > Possibly related to bug 1379895? Can you narrow things down with > mozregression? I do not know if this is related to the fix added by this patch, but I do not have stylo enabled.

That patch changed Servo behavior wrt font weights to match Gecko. Previously Servo would not accept font-weight values that were not multiples of 100 and within a certain range, now Servo is fine with any positive font-weight value (since Pango and other libraries allow and produce nonstandard values). Gecko was always ok with this. I don't think that patch is related to this bug.

last good: https://hg.mozilla.org/mozilla-central/rev/131e19a573e901fb4d01b471b11b7916420b9fee (Nightly 2017-07-25-10-03-46) first bad: https://hg.mozilla.org/mozilla-central/rev/07484bfdb96bc7297c404e377eea93f1d8ca4442 (Nightly 2017-07-25-14-40-53) I am currently bisecting inbound in order to find which patch introduce this regression.

First bad commit: Author: Gian-Carlo Pascutto <gcp@mozilla.com> Date: Mon Jul 24 16:32:22 2017 +0200 Bug 1308400 - Support file process, whitelist path prefs. r=jld Knowing that I am running NixOS, the problem is likely coming from: https://hg.mozilla.org/integration/mozilla-inbound/rev/167f91f87172c3fd4ca7ac8f8e1f6bd6a2bf2dc1#l6.71 Would it be possible to have a list of non-hard-coded paths? Such as through environment variables?

https://wiki.mozilla.org/Security/Sandbox#Customization_Settings Where do the fonts live on NixOS?

(In reply to Gian-Carlo Pascutto [:gcp] from comment #10) > https://wiki.mozilla.org/Security/Sandbox#Customization_Settings > > Where do the fonts live on NixOS? In various directory under /nix/store/, and some are sym-link in ~/.nix-profile/* as they are installed manually. On a similar note, of distributions which are not following the FHS, there is Guix (/gnu) and GoboLinux.

(In reply to Nicolas B. Pierron [:nbp] from comment #11) > On a similar note, of distributions which are not following the FHS, there > is Guix (/gnu) and GoboLinux. Ok. These distro's should probably package their Firefox with modified default prefs.js including the sandbox preferences from comment 10. (or if you install it manually, you'll have to put them yourself) Our current sandboxing implementation can't guarantee a reasonable security level unless it has some idea where various file live, and we won't be able to move to a more compatible alternative with more serious re-engineering of Firefox itself. If there's some specific set of subdirs in /nix/store that contain fonts and GTK theming info, and do not contain sensitive information (there's some leeway here for the sake of compatibility - I currently whitelist /etc!), I can whitelist them in the default build of Firefox. Same for ~/.nix-profile/*.

(In reply to Gian-Carlo Pascutto [:gcp] from comment #12) > we won't be able to move to a more compatible alternative with more serious re-engineering of > Firefox itself. Posting before coffee is bad. ...without more serious re-engineering...

(In reply to Gian-Carlo Pascutto [:gcp] from comment #12) > (In reply to Nicolas B. Pierron [:nbp] from comment #11) > > On a similar note, of distributions which are not following the FHS, there > > is Guix (/gnu) and GoboLinux. > > If there's some specific set of subdirs in /nix/store that contain fonts and > GTK theming info, and do not contain sensitive information (there's some > leeway here for the sake of compatibility - I currently whitelist /etc!), I > can whitelist them in the default build of Firefox. Same for > ~/.nix-profile/*. For what is worth /nix/store/ directory is made to be a read-only public resources, and we are not supposed to put any secrets in these directories. While this might happen, this is already a known issue which should be fixed in some other way. Setting "security.sandbox.content.read_path_whitelist" to "/nix/store/" fixes this issue on nightly. Is there a simple way to have a custom all.js / pref.js for developers, without having to maintain uncommited changes?

Comment on attachment 8892820 [details] Bug 1385253 - Whitelist main NixOS data store directory. https://reviewboard.mozilla.org/r/163808/#review169490

Pushed by gpascutto@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9a01a7a8bb4e Whitelist main NixOS data store directory. r=jld

(In reply to Nicolas B. Pierron [:nbp] from comment #14) > For what is worth /nix/store/ directory is made to be a read-only public > resources, and we are not supposed to put any secrets in these directories. > While this might happen, this is already a known issue which should be fixed > in some other way. > > Setting "security.sandbox.content.read_path_whitelist" to "/nix/store/" > fixes this issue on nightly. Ok. We probably can't feasibly support every distribution out of the box with a path based broker (which is all we've got so far), particularly those who don't want to follow the FHS, but this is one-line fix without downsides, so in it goes.

Please request Beta approval on this when you get a chance.

We will back out (read: disable the pref, as soon as bug 1386558 lands) read-blocking sandboxing from Firefox 56 (beta) so there's no need.