I struggled for a while with jpg image files not properly opening with the “System Handler” in Thunderbird. Despite changing the file association setting back to “Always ask” to reset it, the wrong application opened the images.
Usually one would just select another application in the list of applications but since it is a Flatpak the sandbox restricts access and none where displaying.
Fiddling around I deleted the second order in the chain where Thunderbird Flatpak searches for the right application to open (after the handlers.json):
After a restart the “System Handler” finally opened up the correct application as it was using the third level in the lookup chain, the XDG Desktop Portal, which gracefully forwarded the request to Loupe in this case.
Since Toolbx mounts are running in different namespaces than the host, the mounts cannot be accessed from the latter. I tried many workarounds to see if it really was possible to get around this limit. After some time I decided that using the network stack was probably a better solution to communicate between Toolbx and host.
In my particular case I never do any layering but instead try to use Flatpak, Toolbx, or even a Boxes virtual machine for any specific software not included in the base layering.
I needed to run restic to access some documents on a remote restic repo backup. Since restic is not included I had to use Toolbx for this task. Restic uses FUSE to mount the remote end on the local system. In an ideal world I could just have opened this mount in Dolphin to search and open the needed documents. However due to the namespaces difference this mount just shows empty on the host.
A really quick and dirty solution is to simply use rclone and its webdav option, then Dolphin just opens the webdav address with no issues. Yes, there is a tiny performance hit, but the speed and easy execution greatly makes up for this:
restic mount ~/remote-restic
Now that the mount is working from Toolbx itself run rclone to serve it over the network:
Crashes when trying to attach a file or save an attachment:
[Parent 3, Main Thread] WARNING: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.: 'glib warning', file /builddir/build/BUILD/thunderbird-140.3.0-build/thunderbird-140.3.0/toolkit/xre/nsSigHandlers.cpp:201
(net.thunderbird.Thunderbird:3): Gtk-WARNING **: 12:25:17.580: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /run/host/share/icons/breeze/status/16/image-missing.svg: Failed to create file “~/.var/app/net.thunderbird.Thunderbird/cache/tmp/gdk-pixbuf-glycin-tmp.KSAZE3”: No such file or directory (g-file-error-quark, 4)
Bail out! Gtk:ERROR:../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /run/host/share/icons/breeze/status/16/image-missing.svg: Failed to create file “~/.var/app/net.thunderbird.Thunderbird/cache/tmp/gdk-pixbuf-glycin-tmp.KSAZE3”: No such file or directory (g-file-error-quark, 4)
Redirecting call to abort() to mozalloc_abort
Exiting due to channel error.
Segmentation fault (core dumped) thunderbird
[📦 net.thunderbird.Thunderbird ~]$ exit
exit
There is already a Bugzilla entry but until it is solved you can simply remove the TMPDIR environment variable:
As of today Fedora is at version 42, but simply change the release version to the desired target for any past/future version.
Please note that only one release version jump is supported by Fedora, e.g. from 41 to 42. If you need to upgrade from older versions to the latest, simply run the one-liner sequentially after each reboot.
Using Fedora Kinoite Thunderbird comes in a Flatpak. This caused me issues with mailto links in Firefox not opening Thunderbird’s new email window.
Usually just setting Thunderbird as the default email client inside Thunderbird’s settings or KDE’s default applications would have worked. Even selecting Thunderbird inside the Firefox file handler applications settings would have done the job. However mailto links did nothing but open up the application selector in Firefox which did not work.
The first two places were already set correctly (in Thunderbird and KDE) so not much more to do there. As I cannot directly select Thunderbird’s binary since it is a Flatpak, I tried to get Firefox to open the Flatpak binary instead and somehow customise the command being run.
There was just no way to customise the command through its interface, unless I fiddled with handlers.json directly in my Firefox profile directory. I tried a few combinations and no dice. I was also still reluctant to believe that all other users would go through this mess just to get mailto links working which is such a basic feature.
The most annoying part was that XDG actually returned Thunderbird as the default handler for mailto links:
But checking my ~/.config/mimeapps.list file revealed that there was no mailto handler defined. Adding the corresponding entries finally fixed the issue:
Glad that I got it working but still not satisfied that this was really the way to go, so I decided to start from scratch.
I went back to KDE’s System Settings>Apps & Windows>Default Applications>Email client. Despite having Thunderbird already selected I went and selected Other… instead. Here I could select Thunderbird again but interestingly there were more options:
You will notice in my screen-shot the check-box stating “Remember application association for all files of type “x-scheme-handler/mailto“. This check-box once checked actually updates the same ~/.config/mimeapps.list file with the previous entries I mentioned earlier.
So apparently this is an option which is not enabled by default when just selecting Thunderbird in the default applications list. Why not having mailto links working by default in KDE is a conundrum.
I am sure there are edge cases not wanting mailto links to open the default email client, but I would assume the vast majority of users expect this behaviour of the default email client. What is the point otherwise of selecting a default application?
