Firejail: nosound and GTK menu lag

Created on 9 Feb 2019  路  6Comments  路  Source: netblue30/firejail

Ok, this is an odd one... I've noticed lag in the menus of GTK applications when the option nosound is active in the profile.

The problem:
Using the main menus (File, Edit, View, and so on) there is noticable lag and spacing weirdness when run inside of firejail. I've noticed it in claws-mail, geany, gimp and inkscape so far, but there are probably many more, I don't much use GTK applications.

This is on Arch Linux, KDE Plasma all up to date, firejail 0.9.58-1. Problem also present in earlier versions of firejail (I've had this problem for as long as I can remember).

To reproduce exactly what I'm seeing:
Download and boot live iso manjaro-kde-18.0.2-stable-x86_64.iso (to optionally get a very similar environment)
Run sudo pacman -Sy claws-mail firejail
Start up claws-mail, click through the wizard and then try the menus using the mouse cursor. Transitions should be fast, responsive, normal.
Now run firejail claws-mail. Try the menus again. Focus especially on transitions between different menus, like from Edit->View->Message and back again. The menus start lagging and glitching on transitions. It's as if there is a small spacer between each menu label causing it.

The fix:
Edit /etc/firejail/claws-mail.profile and comment out nosound. Menu behavior is now back to normal when using firejail.

GIMP, Geany and Inkscape show the same behavior. It's not limited to the menus either, I've experienced lag in other places too. Claws, GIMP and Inkscape are GTK2 I think, Geany is GTK3. As a test, I added nosound to the deadbeef profile, because it's easy to switch between GTK2 and 3 in the settings. Both versions show menu lag inside firejail.

But: hexchat has nosound in its profile, uses GTK2 I believe, yet does not show this behavior in the menus. So it doesn't affect all GTK applications I guess.

Reading the firejail manual, nosound disables the sound system. How this can affect the performance in the menus, well, I'll leave that up to you guys...

For now I've added ignore nosound to my relevant .local files. This probably affects a lot of applications, but I'm glad it was easy to work around.

information workaround

Most helpful comment

Hi @hubiqs, very odd indeed. I use Arch Linux too and cannot reproduce here. All menu operations smooth and normal. Mainly using GNOME/GTK apps instead of anything KDE though. Testing all applications you mentioned on my machine with all of the --debug options (see man firejail) and comparing with/without nosound don't show anything unusual here that could start to explain your issues. On a side-note, do you happen to use any of the extras mentioned in the Arch Wiki to give Qt and GTK apps a more uniform look? Or a non-default theme?

The fix:
Edit /etc/firejail/claws-mail.profile and comment out nosound. Menu behavior is now back to normal when using firejail.

Use /etc/firejail/claws-mail.local or ~/.config/firejail/claws-mail.local to change default profile options, so you avoid loosing those on every firejail upgrade.

Do you notice any relevant differences when running affected apps with the --debug options firejail provides? E.g. theme-related paths being blacklisted/whitelisted when using nosound compared to --ignore=nosound or anything like that? Do you get the same behavior when using the AUR git package?

Example debug commands:

$ firejail --debug claws-mail 2>&1 | tee incl-nosound.log
$ firejail --debug --ignore=nosound claws-mail 2>&1 | tee excl-nosound.log

$ firejail --debug-blacklists claws-mail 2>&1 | tee blacklists-incl-nosound.log
$ firejail --debug-blacklists --ignore=nosound claws-mail 2>&1 | tee blacklists-excl-nosound.log

$ firejail --debug-whitelists claws-mail 2>&1 | tee whitelists-incl-nosound.log
$ firejail --debug-whitelists --ignore=nosound claws-mail 2>&1 | tee whitelists-excl-nosound.log

Regards

All 6 comments

Hi @hubiqs, very odd indeed. I use Arch Linux too and cannot reproduce here. All menu operations smooth and normal. Mainly using GNOME/GTK apps instead of anything KDE though. Testing all applications you mentioned on my machine with all of the --debug options (see man firejail) and comparing with/without nosound don't show anything unusual here that could start to explain your issues. On a side-note, do you happen to use any of the extras mentioned in the Arch Wiki to give Qt and GTK apps a more uniform look? Or a non-default theme?

The fix:
Edit /etc/firejail/claws-mail.profile and comment out nosound. Menu behavior is now back to normal when using firejail.

Use /etc/firejail/claws-mail.local or ~/.config/firejail/claws-mail.local to change default profile options, so you avoid loosing those on every firejail upgrade.

Do you notice any relevant differences when running affected apps with the --debug options firejail provides? E.g. theme-related paths being blacklisted/whitelisted when using nosound compared to --ignore=nosound or anything like that? Do you get the same behavior when using the AUR git package?

Example debug commands:

$ firejail --debug claws-mail 2>&1 | tee incl-nosound.log
$ firejail --debug --ignore=nosound claws-mail 2>&1 | tee excl-nosound.log

$ firejail --debug-blacklists claws-mail 2>&1 | tee blacklists-incl-nosound.log
$ firejail --debug-blacklists --ignore=nosound claws-mail 2>&1 | tee blacklists-excl-nosound.log

$ firejail --debug-whitelists claws-mail 2>&1 | tee whitelists-incl-nosound.log
$ firejail --debug-whitelists --ignore=nosound claws-mail 2>&1 | tee whitelists-excl-nosound.log

Regards

Hi @glitsj16, thanks for your reply.

I've been experimenting using live ISOs to narrow this down a bit.

My local Arch+KDE installs - problem present
Manjaro KDE ISO 18.0.2 - problem present
Manjaro XFCE ISO 18.0.2 - no problems
KDE Neon ISO 20190124 - no problems

So it's possibly limited to _some GTK applications on Arch-based distros when used with KDE Plasma_..?

I'm not used to tracking down bugs but I've made some logs like you suggested from Manjaro KDE and XFCE live ISOs, since they should be very similar, yet only one exhibits the problem. For Manjaro KDE, I reset all theme options to resemble Plasma defaults, using Breeze theme and Adwaita for GTK to get rid of Manjaro stylings. (Manjaro's Breath theme generates a GTK warning about some theme element, Adwaita doesn't.)

For testing I use claws-mail. I open the Configuration menu, then quickly shift over to Tools->Message->View using the mouse cursor and then back and forth a few times. These big adjacent menus display the problem well, they are slow and appear to remain open, flashing and glitching.

Log files for Manjaro KDE:
kde-incl-nosound.log (laggy)
kde-excl-nosound.log
kde-blacklists-incl-nosound.log (laggy)
kde-blacklists-excl-nosound.log

Log files for Manjaro XFCE:
xfce-incl-nosound.log
xfce-excl-nosound.log
xfce-blacklists-incl-nosound.log
xfce-blacklists-excl-nosound.log

(Apologies for using Pastebin, I'm not very used to Github.)
I've diffed the files, but nothing in particular stands out to me.

I don't recall ever doing any of the Qt-GTK stuff from the Wiki. Anyway the Manjaro KDE live ISO config could be fully inspected as it displays the same problem. I've also tried the firejail-git package, but it made no difference. And I also tried disabling the compositor in Plasma, it makes the menus stop flashing, but the lag is still there. By the way I'm using Intel graphics and KMS if it should matter.

Perhaps the problem is too specific to be worth pursuing, but anyone is welcome to try the live ISOs and see if you can find out what's causing this. It may seem like I'm nitpicking here but it really is an annoyance, and these problems seen as a whole make the affected applications feel slow and broken.

I guess I'm at my wit's end here, but at least there is a functioning workaround. I'm adding ignore nosound to my relevant .local files from now on. I suppose allowing some applications to access the sound system doesn't matter much anwyay.

Does Arch use Wayland for KDE by default?

Does Arch use Wayland for KDE by default?

Nope, this is all using X.

@hubiqs Thanks for offering those logs. Absolutely no need to apologize, pastebin is just fine. It would have been too easy if something stood out diff'ing your logs I suppose. Alas, looking at those, everything seems to run as expected. Cheers for reporting, at least users experiencing similar issues can try your workaround.

Any progress here?

Was this page helpful?
0 / 5 - 0 ratings