Where Thunderbird seems to get your default browser from on Linux

June 20, 2024

Today, I had a little unhappy experience with Thunderbird and the modern Linux desktop experience:

Dear Linux Thunderbird, why are you suddenly starting to open links I click on in Chrome? I do not want that in the least, and your documentation on how you obtain this information is nonexistent (I am not on a Gnome or KDE desktop environment). This worked until relatively recently and opened in the right browser, but now it is opaquely broken.

This is an example of why people want to set computers on fire.

(All of this is for Thunderbird 115.12 on Fedora 40. Other Linux distributions may differ, and things may go differently if you're using KDE.)

After some investigation, I now know where Thunderbird was getting this information from and why it wound up on Chrome, although I don't know what changed so that this started happening recently. A critical source for my journey was Kevin Locke's Changing the Default Browser in Thunderbird on Linux, originally written in 2012, revised in 2018, and still applicable today, almost six years later.

If you're an innocent person, you might think that Thunderbird would of course use xdg-open to open URLs, since it is theoretically the canonical desktop-independent way to open URLs in your browser of choice. A slightly less innocent person could expect Thunderbird to use the xdg-mime tool and database to find what .desktop file handles the 'x-scheme-handler/https' MIME type and then use it (although this would require Thunderbird to find and parse the .desktop file).

Thunderbird does neither of these. Instead, it uses the GTK/Gnome 'gconf' system (which is the old system, in contrast to the new GSettings), which gives Thunderbird (and anyone else who asks) the default command to run to open a URL. We can access the same information with 'gconftool-2' or 'gconf-editor' (don't confuse the latter with dconf-editor, which works on GSettings/dconf). So:

$ gconftool-2 --get /desktop/gnome/url-handlers/http/command
gio open %s

The 'gio' command provides command line access to the GTK GIO system, and is actually what xdg-open would probably use too if I was using a Gnome desktop instead of my own weird environment. We can check what .desktop file 'gio' will use and compare it to xdg-mime with:

$ xdg-mime query default x-scheme-handler/https
org.mozilla.firefox.desktop
$ gio mime x-scheme-handler/https
Default application for “x-scheme-handler/https”: google-chrome.desktop
Registered applications:
        google-chrome.desktop
        kfmclient_html.desktop
        org.midori_browser.Midori.desktop
        org.mozilla.firefox.desktop
Recommended applications:
        google-chrome.desktop
        kfmclient_html.desktop
        org.midori_browser.Midori.desktop
        org.mozilla.firefox.desktop

So GIO and xdg-mime disagree, and GIO is picking Chrome.

(In case you're wondering, Thunderbird really does run 'gio open ...'.)

What happened to me is foreshadowed by my 2016 entry on how xdg-mime searches for things. I had a lingering old set of files in /usr/local/share/applications and the 'defaults.list' there contained (among a few other things):

[Default Applications]
x-scheme-handler/http=mozilla-firefox.desktop;google-chrome.desktop
x-scheme-handler/https=mozilla-firefox.desktop;google-chrome.desktop

The problem with these entries is that there's no 'mozilla-firefox.desktop' (or 'firefox.desktop') any more; it was long since renamed to 'org.mozilla.firefox.desktop'. Since there is no 'mozilla-firefox.desktop', it is ignored and this line really picks 'google-chrome.desktop' (instead of ignoring Chrome). For a long time this seems to have been harmless, but then apparently GIO started deciding to pay attention to /usr/local/share/applications, although xdg-mime was ignoring it. Getting rid of those 2013-era files made 'gio mime ...' agree that org.mozilla.firefox.desktop was what it should be using.

(The Arch wiki page on Default Applications has some additional information and pointers. Note that all of this ignores /etc/mailcap, although some things will use it.)

This is still not what I want (or what it used to be), but fixing that is an internal Thunderbird settings change, not Thunderbird getting weird system settings.

Sidebar: Fixing Thunderbird to use a browser of your choice

This comes from this superuser.com answer. Get into the Config Editor (the Thunderbird version of Firefox's 'about:config') and set network.protocol-handler.warn-external.http and network.protocol-handler.warn-external.https to 'true'. To be safe, quit and restart Thunderbird. Now click on a HTTPS or HTTP link in a message, and you should get the usual 'what to do with this' dialog, which will let you pick the program of your choice and select 'always use this'. Under some circumstances, post-restart you'll be able to find a 'https' or 'http' entry in the 'Files & Attachments' part of 'General' Settings, which you can change on the spot.

Written on 20 June 2024.
« It seems routine to see a bunch of browser User-Agents from the same IP
The IMAP LIST command as it interacts with client prefixes in Dovecot »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jun 20 23:02:47 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.