Launchpad has imported 53 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1495900.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2018-10-02T21:53:50+00:00 L. David Baron wrote: Sometime in the past few weeks I've noticed a regression: when I start Chromium (Ubuntu's packaged version of it) to test something, all of my Firefox content processes hang for about 2 minutes. This is pretty bad! Today I decided to profile, and the profile at https://perfht.ml/2y8pYIS showed what I expected to be the problem: FontConfig. In particular, we spend basically all of the time inside FcInitReinitialize. I'm not sure if the thing that caused the regression is something in Chromium (e.g., a change in version 69, which I got the upgrade to on 2018-09-12, which seems plausible for when this started happening), or whether the regression is on the Firefox side. [Tracking Requested - why for this release]: Either way, spending this much time rescanning font directories just because I started Chromium doesn't seem acceptable, and seems likely to be problematic for any Web developers running Linux. On the flip side, it's possible my times are particularly long because I have a lot of fonts installed. (I don't have a particularly large number of active tabs -- probably about 20-30, though I have a very large number of dormant tabs that haven't been loaded but are part of my session. If we do something once per tab, that could certainly be a problem...) The bulk of the time (again, see the profile at https://perf- html.io/public/e0db389afe6c3fdcafc8df3db7f0ec0447a1f432 ) is spent in stacks like this: TT_New_Context FT_Load_Glyph FcPatternFormat FcPatternFormat FcFreeTypeQueryFace FcFileIsDir FcFileIsDir FcDirScan FcConfigAppFontClear FcConfigBuildFonts FcInitLoadConfig FcInitReinitialize gtk_settings_get_type g_closure_invoke g_signal_handler_disconnect g_signal_emit_valist g_signal_emit g_cclosure_marshal_BOOLEAN__BOXED_BOXEDv g_object_notify_by_pspec gtk_main_do_event gdk_event_free gdk_x11_drag_context_get_type g_main_context_dispatch g_main_context_dispatch g_main_context_iteration nsAppShell::ProcessNextNativeEvent(bool) nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) non-virtual thunk to nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) nsThread::ProcessNextEvent(bool, bool*) NS_ProcessNextEvent(nsIThread*, bool) mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) MessageLoop::Run() nsBaseAppShell::Run() XRE_RunAppShell() MessageLoop::Run() XRE_InitChildProcess(int, char**, XREChildData const*) XRE_InitChildProcess Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/0 ------------------------------------------------------------------------ On 2018-10-03T08:09:43+00:00 Jfkthame wrote: Looks like this is not only within fontconfig, it's within fontconfig called from GTK code. That seems like it may not really be under our control. I guess what's happening is that when chromium is started, it's changing the (global) fontconfig configuration in such a way that fontconfig (in any process that uses it) decides it needs to reinitialize everything. What version of fontconfig is installed? This might be a fontconfig issue that is fixed in newer versions; see also bug 1411338 comment 11. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/1 ------------------------------------------------------------------------ On 2018-10-04T00:46:50+00:00 L. David Baron wrote: $ dpkg -l 'fontconfig*' | grep "^ii" ii fontconfig 2.12.6-0ubuntu2 amd64 generic font configuration library - support binaries ii fontconfig-config 2.12.6-0ubuntu2 all generic font configuration library - configuration Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/2 ------------------------------------------------------------------------ On 2018-10-04T01:05:59+00:00 L. David Baron wrote: Created attachment 9014241 more accurate callstack Here's a more accurate callstack from gdb. There seems to be a single call per child process, and that single call really does take a few minutes. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/3 ------------------------------------------------------------------------ On 2018-10-04T01:07:24+00:00 L. David Baron wrote: Oh, and the version you really wanted is: ii libfontconfig1:amd64 2.12.6-0ubuntu2 amd64 generic font configuration library - runtime ii libfontconfig1:i386 2.12.6-0ubuntu2 i386 generic font configuration library - runtime but it's the same. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/4 ------------------------------------------------------------------------ On 2018-10-04T11:45:49+00:00 Jfkthame wrote: Judging by the discussion in bug 1411338, I suspect this is a fontconfig 2.12.x issue and the fix is to update to fontconfig-2.13 or later. Could you try that and confirm whether it resolves the problem? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/5 ------------------------------------------------------------------------ On 2018-10-04T22:07:16+00:00 L. David Baron wrote: (In reply to Jonathan Kew (:jfkthame) from comment #5) > Judging by the discussion in bug 1411338, I suspect this is a fontconfig > 2.12.x issue and the fix is to update to fontconfig-2.13 or later. Could you > try that and confirm whether it resolves the problem? That reduces the pause from 2-3 minutes to about 4-5 seconds, though there's still a pause. (I updated to the fontconfig packages from cosmic (i.e., Ubuntu 18.10), which are version 2.13.0-5ubuntu3.) Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/6 ------------------------------------------------------------------------ On 2018-10-16T22:02:05+00:00 Jfkthame wrote: *** Bug 1492360 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/7 ------------------------------------------------------------------------ On 2018-10-19T09:26:50+00:00 Julien Cristau wrote: Is there anything we can do here to avoid/reduce the pause or is this a wontfix? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/8 ------------------------------------------------------------------------ On 2018-10-19T10:34:02+00:00 Jfkthame wrote: I'm not sure. I don't see an obvious way forward, but the behavior is pretty bad. :( Are any other (gtk-using) applications similarly affected? Given that the pause occurs because a fontconfig re-scan appears to be triggered from inside gtk event-handling code, it seems like other processes might be suffering the same issue. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/9 ------------------------------------------------------------------------ On 2018-10-24T16:45:18+00:00 Jfkthame wrote: *** Bug 1499824 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/10 ------------------------------------------------------------------------ On 2018-10-25T20:17:29+00:00 Simon wrote: Just wanted to pipe up and confirm that installing the latest fontconfig packages from cosmic significantly reduced the wait time for me, which makes running my tests a whole lot more manageable :) For the record I just installed these debs: http://mirrors.kernel.org/ubuntu/pool/main/f/fontconfig/fontconfig-config_2.13.0-5ubuntu3_all.deb http://mirrors.kernel.org/ubuntu/pool/main/f/fontconfig/libfontconfig1_2.13.0-5ubuntu3_amd64.deb Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/11 ------------------------------------------------------------------------ On 2018-11-01T03:33:23+00:00 Ryanvm wrote: Is there anything more we can do here? Not sure what to do with the Fx64 tracking request since this sounds like an issue that's out of our control. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/12 ------------------------------------------------------------------------ On 2018-11-01T10:19:16+00:00 Jfkthame wrote: I don't know of any way forward here, unfortunately. The one thing I'd be curious to know is whether other Gtk-based applications are similarly affected; it seems like they should be, given that the issue seems to be happening where fontconfig is used from within Gtk code rather than directly from Gecko. (It may be much less noticeable, though, if the app isn't visibly busy during the Chrome launch.) David, can you try to see whether other apps are affected on your system, especially when using the older fontconfig? If this actually is unique to Firefox, that would suggest there might be something about how we use Gtk that's provoking it. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/13 ------------------------------------------------------------------------ On 2018-11-03T23:28:56+00:00 Byte Commander wrote: *** Bug 1504461 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/14 ------------------------------------------------------------------------ On 2018-11-06T13:50:24+00:00 Julien Cristau wrote: FWIW I asked a contact on the ubuntu desktop team a couple of weeks ago, it sounds like they hadn't seen this reported on their side, either for firefox or other applications. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/15 ------------------------------------------------------------------------ On 2018-11-13T19:55:42+00:00 L. David Baron wrote: I'm reasonably confident that gnome-terminal wasn't affected, although I didn't retest (by downgrading) just now. Are there other apps that are more Firefox-like that you'd want me to check? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/16 ------------------------------------------------------------------------ On 2018-11-13T20:08:54+00:00 L. David Baron wrote: I tried setting a breakpoint on settings_update_fontconfig in some other GTK apps (gnome-system-monitor, gnome-terminal-server), and I didn't even hit it when starting Chromium, whereas I do hit it in Firefox. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/17 ------------------------------------------------------------------------ On 2018-11-13T20:45:17+00:00 Jfkthame wrote: I wonder if apps like gnome-system-monitor or terminal don't do as much with font configuration? How about something like Gedit or LibreOffice -- do they hit settings_update_fontconfig at all? Speculation: maybe it's related to the fact that we register a callback to be notified when there's a change in Gtk default settings (see <https://searchfox.org/mozilla- central/rev/007b66c1f5f7a1b9a900a2038652a16a020f010c/widget/gtk/nsWindow.cpp#4073-4081>). If you comment out that block of code, does it make any difference? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/18 ------------------------------------------------------------------------ On 2018-11-13T20:48:31+00:00 L. David Baron wrote: So one difference I found between Firefox and gnome-system-monitor is that in Firefox, we execute this check_manager_window function that sets up the gdk_xsettings_manager_window_filter event filter that leads to an XEvent (property change) being turned into the fontconfig notification. However, in gnome-system-monitor there's a call to gtk_init but it doesn't reach check_manager_window. Here's the Firefox callstack: #0 0x00007f071684ebf0 in check_manager_window (x11_screen=0x5612c32c4020 [GdkX11Screen], notify_changes=notify_changes@entry=0) at ../../../../../gdk/x11/xsettings-client.c:527 #1 0x00007f071684edc6 in _gdk_x11_xsettings_init (x11_screen=<optimized out>) at ../../../../../gdk/x11/xsettings-client.c:618 #2 0x00007f0716830e3c in _gdk_x11_display_open (display_name=<optimized out>) at ../../../../../gdk/x11/gdkdisplay-x11.c:1608 #3 0x00007f0716805d5d in gdk_display_manager_open_display (manager=<optimized out>, name=0x5612c32a1480 ":0") at ../../../../gdk/gdkdisplaymanager.c:472 #4 0x00007f0716cf4ffa in gtk_init_check (argc=<optimized out>, argv=<optimized out>) at ../../../../gtk/gtkmain.c:1104 #5 0x00007f0716cf5029 in gtk_init (argc=<optimized out>, argv=<optimized out>) at ../../../../gtk/gtkmain.c:1161 #6 0x00007f070b12d90c in mozilla::dom::ContentChild::Init(MessageLoop*, int, char const*, IPC::Channel*, unsigned long, bool) (this=0x5612c329d060, aIOLoop= 0x7f0703d66cc8, aParentPid=10218, aParentBuildID=0x7ffd28fa8a3a "20180917145248", aChannel=0x7f06fc002560, aChildID=1, aIsForBrowser=<optimized out>) at /home/dbaron/builds/mozilla-central/mozilla/dom/ipc/ContentChild.cpp:656 Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/19 ------------------------------------------------------------------------ On 2018-11-13T20:50:04+00:00 L. David Baron wrote: gedit, like gnome-system-manager, does not hit settings_update_fontconfig, and also does not call check_manager_window within gtk_init. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/20 ------------------------------------------------------------------------ On 2018-11-13T20:53:24+00:00 L. David Baron wrote: And the difference is because in gedit, gdk_display_manager_open_display tries _gdk_wayland_display_open first, and it succeeds, so there's no x11 display at all. So, basically, I think it doesn't happen in gedit because the notification code for fontconfig changes was never hooked up for wayland. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/21 ------------------------------------------------------------------------ On 2018-11-13T21:00:18+00:00 L. David Baron wrote: Not sure if the above leads to anything useful... Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/22 ------------------------------------------------------------------------ On 2018-11-23T16:12:10+00:00 Mike Conley wrote: *** Bug 1499385 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/23 ------------------------------------------------------------------------ On 2018-12-03T15:47:32+00:00 Julien Cristau wrote: This is likely wontfix for 64 at this point, though it'd be good to figure out a way to avoid this. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/24 ------------------------------------------------------------------------ On 2019-05-30T04:14:25+00:00 Mike Conley wrote: *** Bug 1554588 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/25 ------------------------------------------------------------------------ On 2019-06-03T02:15:37+00:00 Hikezoe-birchill wrote: FWIW, this issue probably also happens with Android Emulator as well. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/26 ------------------------------------------------------------------------ On 2019-06-03T02:38:26+00:00 Lsalzman wrote: (In reply to Hiroyuki Ikezoe (:hiro) from comment #26) > FWIW, this issue probably also happens with Android Emulator as well. Android does not use FontConfig, so is not affected by this. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/27 ------------------------------------------------------------------------ On 2019-06-03T02:51:20+00:00 Hikezoe-birchill wrote: (In reply to Lee Salzman [:lsalzman] from comment #27) > (In reply to Hiroyuki Ikezoe (:hiro) from comment #26) > > FWIW, this issue probably also happens with Android Emulator as well. > > Android does not use FontConfig, so is not affected by this. Oh, you mean qemu or something like that doesn't use it at all on Linux? I've been seeing quite often similar issue when I run the emulator. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/28 ------------------------------------------------------------------------ On 2019-06-03T02:59:12+00:00 Hikezoe-birchill wrote: Hmm actually qemu-system-x86_64 doesn't linked to libfontconfig.so (I am not sure it's dynamically loaded or not), so probably some other processes might affect Firefox. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/29 ------------------------------------------------------------------------ On 2019-07-18T04:31:18+00:00 0vximcmlxxv wrote: (In reply to svansintjan from comment #11) > Just wanted to pipe up and confirm that installing the latest fontconfig > packages from cosmic significantly reduced the wait time for me, which makes > running my tests a whole lot more manageable :) > > For the record I just installed these debs: > > http://mirrors.kernel.org/ubuntu/pool/main/f/fontconfig/fontconfig-config_2. > 13.0-5ubuntu3_all.deb > http://mirrors.kernel.org/ubuntu/pool/main/f/fontconfig/libfontconfig1_2.13. > 0-5ubuntu3_amd64.deb Looks like the files specified in these links have a problem. Firefox is complaining that the files have 'Virus or Malware' when trying to download them. I downloaded the same package from 'Launchpad.net', it did not complain - https://launchpad.net/ubuntu/disco/amd64/fontconfig/2.13.1-2ubuntu2 Probably the links need to be removed and people should download the packages from Launchpad. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/30 ------------------------------------------------------------------------ On 2019-11-15T14:01:33+00:00 Mike Conley wrote: *** Bug 1562544 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/31 ------------------------------------------------------------------------ On 2019-11-23T15:05:27+00:00 Jfkthame wrote: *** Bug 1580016 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/32 ------------------------------------------------------------------------ On 2019-12-05T22:37:48+00:00 7-contacto-1 wrote: I am using Ubuntu 18.04, is it possible to fix this? I cant seem to install the deb files provided. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/33 ------------------------------------------------------------------------ On 2019-12-18T09:46:44+00:00 Norsemanna wrote: Hi folks, > David, can you try to see whether other apps are affected on your system actually, when in my spare time, there are only three desktop apps that i use on my system: Firefox, Chromium, and skype. There is actually no difference in handling w.r.t this problem. So starting skype oftentimes freezes chromium and firefox, as well as starting chromium might freeze the others. >This is likely wontfix for 64 at this point, though it'd be good to figure out a way to avoid this. Well, we are at 71 now (in my distribution), and the problem is still there. >That reduces the pause from 2-3 minutes to about 4-5 seconds, though there's still a pause. Well, even 4-5 seconds are too much, when there is a video or a real time financial trader running in the browser, or a chat with a friend just having asked you the "ultimate question" and you cannot answer for several minutes .... --- As user "contacto" above, I cannot install 2.13 on my system due to missing dependencies, and the next stable long time version will not come so soon. Can you please let us know, why firefox has to do this job synchroneously and wait for fontconfig to finish? Can't that be done in an async way? Why does firefox have to update the fonts anyway? If the user installs new fonts, why just don't wait until the user restarts firefox to see the new fonts in the app? How about a user-option to opt-out of this behaviour? Finally: What can we do now to fix this problem? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/34 ------------------------------------------------------------------------ On 2020-01-13T15:09:14+00:00 Morgan Wahl wrote: I seem to have run into this when starting [Atom](https://atom.io/), which uses [Electron](https://electronjs.org/) (which is itself based on Chromium). Every firefox process is at max CPU. Looking at strace it seems to mainly hang out after opening a NotoSansCJK or NotoSerifCJK font. These fonts have 2^16 - 1 glyphs, the maximum for a truetype font. It's possible the delay wouldn't be perceivable without such large fonts installed. Firefox 72.0.1+build1-0ubuntu0.18.04.1 libfontconfig1 2.12.6-0ubuntu2 Ubuntu 18.04.3 LTS x86-64 I believe I'm using X, not Wayland. Can't seem to trigger it with other GTK apps. Tried epiphany, gedit, evince, Gimp, Inkscape, QuodLibet, and LibreOffice Writer (not sure if that's GTK), and Thunderbird (although I don't have an account configured in Thunderbird). Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/35 ------------------------------------------------------------------------ On 2020-01-14T09:00:24+00:00 Norsemanna wrote: Morgan, yes, I have that fonts, too. But even when deactivating Noto*CJK*, the load of the firefox (sub)processes/threads goes up to 95% (while with the Noto*CJK fonts all of them went up to 100+%). Still waiting here for an answer that I can use as a workaround, since I cannot install the 2.13 lib version. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/36 ------------------------------------------------------------------------ On 2020-01-15T01:00:14+00:00 7-contacto-1 wrote: Waiting for a workaround too :( Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/37 ------------------------------------------------------------------------ On 2020-02-05T20:11:31+00:00 Corey-r wrote: This is a very frustrating bug, hoping for a fix soon as possible. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/38 ------------------------------------------------------------------------ On 2020-02-06T02:54:28+00:00 B-emilio wrote: Out of curiosity, does this repro with `MOZ_DISABLE_CONTENT_SANDBOX=1`? I expect it'd be at least much faster with that... Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/39 ------------------------------------------------------------------------ On 2020-02-06T03:23:26+00:00 Hikezoe-birchill wrote: No. As far as I can tell it eliminates the hang completely. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/40 ------------------------------------------------------------------------ On 2020-02-06T03:42:28+00:00 B-emilio wrote: So this may be because we route all the system calls through the parent process, which means that file reads from content have a _lot_ of overhead... Next thing to figure out would be whether the FcReinitialize stuff still happens consistently with the sandbox disabled... Jed, do you know if the broker thread is registered with the profiler? It'd be kinda cool to see where time is spent there if the sandboxing is indeed the culprit. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/41 ------------------------------------------------------------------------ On 2020-02-07T00:57:08+00:00 Jed Davis wrote: I don't think they are, but that could be changed; [this is the top of the broker threads' main function][main-start]. But something else to consider: is fontconfig trying to shell out to `fc-cache` from the content processes? That will fail under sandboxing, and that might explain some of the difference between sandboxed and unsandboxed. One experiment to try there is to set `security.sandbox.content.level` to 1, which should block `fork` but allow direct (unbrokered) filesystem access. [main-start]: https://searchfox.org/mozilla- central/rev/3811b11b5773c1dccfe8228bfc7143b10a9a2a99/security/sandbox/linux/broker/SandboxBroker.cpp#623-630 Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/42 ------------------------------------------------------------------------ On 2020-02-14T01:11:00+00:00 Jed Davis wrote: (In reply to David Baron :dbaron: 🏴 ⌚UTC-8 from comment #0) > Today I decided to profile, and the profile at https://perfht.ml/2y8pYIS > showed what I expected to be the problem: FontConfig. In particular, we > spend basically all of the time inside FcInitReinitialize. In particular, this appears to be spending almost all of the time doing computations in fontconfig itself, not blocked on opening files (seen as `recvmsg` with inverted call stacks), which — assuming the nature of the problem hasn't changed since then — supports the idea that the cause of the bad performance isn't the file brokering, but it might be fontconfig falling back to ignoring a cache after failing to run an external command to rebuild it. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/43 ------------------------------------------------------------------------ On 2020-04-08T07:47:14+00:00 Alexey Ten (Lynn) wrote: I've keep `security.sandbox.content.level` to 4, but whitelisted fontconfig caches ``` user_pref("security.sandbox.content.read_path_whitelist", "/var/cache/fontconfig/,/home/lynn/.cache/fontconfig/"); ``` Now `touch ~/.local/share/fonts/` doesn't make firefox to eat 100% of CPU. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/46 ------------------------------------------------------------------------ On 2020-04-08T09:26:41+00:00 Jfkthame wrote: According to comment 44, it looks like the problem here arises because the sandbox is blocking fontconfig from reading its caches (which then results in it doing a full rescan in each process). So if we add these cache dirs to the sandbox policy, it may help with this issue. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/47 ------------------------------------------------------------------------ On 2020-04-08T09:28:48+00:00 Jfkthame wrote: Created attachment 9139105 Bug 1495900 - Add fontconfig cache directories to content-process sandbox read paths. r=jld Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/48 ------------------------------------------------------------------------ On 2020-04-08T21:17:46+00:00 Hikezoe-birchill wrote: (In reply to Alexey Ten (Lynn) from comment #44) > I've keep `security.sandbox.content.level` to 4, but whitelisted fontconfig > caches > ``` > user_pref("security.sandbox.content.read_path_whitelist", > "/var/cache/fontconfig/,/home/lynn/.cache/fontconfig/"); > ``` > > Now `touch ~/.local/share/fonts/` doesn't make firefox to eat 100% of CPU. FWIW, with the pref value (though I used my home directory) Firefox crashes when a wpt finished running on my environment. bp-8fcb3fe8-6515-4444-8d06-792780200408 Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/49 ------------------------------------------------------------------------ On 2020-04-08T21:49:46+00:00 Jfkthame wrote: > FWIW, with the pref value (though I used my home directory) Firefox crashes when a wpt finished running on my environment. Huh, that's a bit worrying..... it looks a bit like bug 1627605, but that only applies when `gfx.e10s.font-list.shared` is enabled, which I don't see in your crash report. Setting needinfo? to remind myself to see if I can reproduce that locally. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/50 ------------------------------------------------------------------------ On 2020-04-08T23:42:46+00:00 Hikezoe-birchill wrote: Hmm I don't recall when I set gfx.e10s.font-list.shared to false and re- set to true, but today I can't reproduce the crash so far, I think I am using a nightly which is not yet including bug 1627605. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/51 ------------------------------------------------------------------------ On 2020-04-09T12:17:44+00:00 Release-mgmt-account-bot wrote: [Bugbug](https://github.com/mozilla/bugbug/) thinks this bug is a regression, but please revert this change in case of error. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/52 ------------------------------------------------------------------------ On 2020-04-11T09:08:50+00:00 Pulsebot wrote: Pushed by j...@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a58f96ac7e03 Add fontconfig cache directories to content-process sandbox read paths. r=jld Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/53 ------------------------------------------------------------------------ On 2020-04-11T21:53:45+00:00 Btara wrote: https://hg.mozilla.org/mozilla-central/rev/a58f96ac7e03 Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/54 ** Changed in: firefox Status: Unknown => Fix Released ** Changed in: firefox Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1870827 Title: Firefox hangs after simultaneously opening Chrome/Electron-based applications To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1870827/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
