I’ve had this issue for for a very long time and no solution so far, so I decided to give it another shot to see if anyone can help? The strange thing is that this works perfectly fine if I use the Snap version. How ever, I prefer to stick with the Manjaro version. I use Thunderbird as my default mail. The email hyperlink in Chrome doesn’t launch the Thunderbird mail if I use (Official Build) Manjaro version. How ever, the hyperlink launches without any issue in the Snap version ( I have Kubuntu on a second hard drive). I have compared the settings of both Manjaro and Snap version side by side, and they are identical. There must be a security setting or something that Manjaro uses verses the Snap version preventing email to launch, but I can’t figure it out! I have searched, and searched and nothing has worked so far.
Version 101.0.4951.54 (Official Build) Manjaro Linux (64-bit)
Version 101.0.4951.54 (Official Build) snap (64-bit) (Works fine)
System:
Kernel: 5.15.32-1-MANJARO - KDE Plasma v: 5.24.4 Distro: Manjaro Linux base: Arch Linux
@winne, maycne.sonahoz
And…that worked! I’ve been trying to solve this mystery for years, with no success!
What I don’t understand is why does it work with the Snap version without any issue?
Well, not solved yet. It quit working again. Both network.protocol-handler.warn-external.http and https is set on true, but it no longer launches the email.
I did that, but still didn’t work. The wired thing is the exact setup works if use the Snap’s version, and it worked once at the beginning but it stopped working.
Also, I have an exact copy of Manjaro on the same computer, different hard drive to test things before installing anything, and that one still launches the email and works, but I can’t make to launch on my main drive which worked one time!
I thought you were trying to get hyperlinks (within a Thunderbird email message) to open in Chrome instead of Firefox?
You can reset the above flag to “false”, and then have it re-prompt you when you click the hyperlink. You can then tell it to remember this choice (of Chrome).
I have a database with a bunch of customer email addresses. I normally use Firefox to access the client database. It always works, and launches the email on Firefox when I click on the email link for example john1234@gmail.com. How ever, I some time use Chrome and if I click on the same email link, it does not launch the email. Therefore I have to copy and paste into Thunderbird. The wired thing is that same thing in the Snap version with the same version of Chrome and Thunderbird works, and that what’s puzzling!
I also reset the flag back to “false” and then back to “true”, but now it won’t work at all no matter what I do.
There’s seems to be a mixup due to the way you worded your initial post and followup comments.
Now I understand the issue, and sad to say, this is an upstream bug with the Freedesktop Project’s xdg-utils running under KDE.
When you click on a “mailto” link in Google Chrome or Chromium, it invokes the xdg-email command. This command is meant to launch your default email client.
However, under KDE there’s a bug in which it tries to literally execute the .desktop file (i.e, thunderbird.desktop) rather than the binary (i.e, /usr/bin/thunderbird).
Even though it appears that “nothing happens” when you are using Chrome, there’s an error that occurs under-the-hood:
/usr/bin/xdg-email: line 619: thunderbird.desktop: command not found
Firefox, on the other hand, likely uses xdg-open instead of xdg-email, and hence it works without any issues, even under KDE.
The unsettling news is that this bug was reported a year ago, and it looks like no progress has been made yet. Perhaps it’s a matter of "should KDE fix it or should Freedesktop Project fix it?"
For this to be fixed in the future, I would expect at least one of the following three things to happen:
Chrome / Chromium switches to an alternative method (like Firefox uses), such as xdg-open instead of xdg-email
The Freedesktop Project fixes this bug upstream in xdg-utils
KDE fixes the issue when invoking xdg-email so that it parses the .desktop file to launch the actual binary, rather than the .desktop file itself