Arch Linux

Oh, as an additional note, I'm using dwm, so there should be no other mime type handler in the way.

The attached patch against 1.1.0rc1-3's /usr/bin/xdg-open adds proper handling for magnet links. It doesn't step on other URIs, so should be safe to drop into any system.

@tepidpond - applied this patch but still no magnet links from chromium :/

If you're under xfce, Gnome, or KDE, the DE-native tool takes precedence. Without a DE, with a clean Chromium profile, and having just done a full upgrade, it works here. The troubleshooting I can think of is: Does 'xdg-open magnet:?xt=foo' at a console launch your torrent client(note that lacking a correct URI there means a pre-launched client will silently ignore it and appear to have failed)? Does 'xdg-mime query default "x-scheme-handler/magnet"' return the .desktop file of your chosen torrent client?

@tep - I'm using lxde.

$ xdg-mime query default "x-scheme-handler/magnet"
$

Returns nothing. Just a fresh prompt.

$ xdg-open magnet:?xt=foo
magnet:?xt=foo
magnet:?xt=foo

You don't seem to have a mime-handler set for magnet links. Run 'xdg-mime default transmission-gtk.desktop application/x-bittorrent x-scheme-handler/magnet', replacing transmission-gtk.desktop with the desktop file for whichever torrent client you actually want to run.

Success! Thanks! Odd thing is that I have to launch deluge manually and then click the link or else clicking a magnet link only loads deluge. Clicking it a 2nd time transfers the link. Anyway, thank you.

Patch works here for chromium and xdg-utils 1.1.0rc1-3. Thank you!

Here's a slightly revised patch. Tepidpond's patch didn't work for me as written -- the threshold problem was with the variable $1 losing its contents along the way (don't know why, but it might have to do something with subshells being called within the script...bash scripting is definitely not my strong suit). I replaced it with $url (which is defined as $1 earlier in the script, before $1 disappears) and that problem was solved.

A more serious problem was that the open_generic function was not properly calling the open_generic_xdg_mime function. Something bad was happening along the way, but rather than untangle what looked like a somewhat complicated bit of code, I hacked a quick and dirty solution and merely tested for the presence of the "magnet:?xt=" string in the main part of the script, running the open_generic_xdg_mime function if the string was found. That fixed it right up.

My patch is not meant to represent finished work; it's a quick and dirty patch of a patch that works for me and I am sharing it only to shed further light on the underlying bug. All credit to tepidlake, all criticism to me.

It is possible that my particular problems with the original patch are due to the fact that I'm not even running Arch Linux. I'm running Debian 6.0, with Xfce 4.6.2, and on a backported 3.2 kernel from the Debian repos (version 3.2.0-0.bpo.2-amd64). But since I found the solution to this problem on an Arch Linux forum, other people running various distros may also chance upon it -- the underlying bug certainly doesn't appear to be distro-specific.

(I'm using Chrome version 18.0.1025.168, but it shouldn't matter as this bug is not browser-related.)

Please check xdg-utils-1.1.0-0.20120520-any.pkg.tar.xz in testing if this has been solved or file an upstream issue to get your patch included.

How's xdg-utils 1.1.0-2.20120520 solving a packaging issue now really using latest git scripts?

-2 causes problems for me. I use archlinux-xdg-menu for opening a browser with the Arch Linux websites, and it seems like xdg-open cuts off the "http:" from the URL. I am using conkeror as default browser.

Forgot to add: downgrading to -0 fixes the issue for me.

Then there's some regression in new git scripts we generate. Try to locate it and report it upstream.

I think the whole issue may be related to the bug already submitted to freedesktop.org:

Bug 45859 - xdg-open fails to open a url in a "generic" environment
https://bugs.freedesktop.org/show_bug.cgi?id=45859

I have posted about it to the arch-general too:
http://mailman.archlinux.org/pipermail/arch-general/2012-June/027247.html

The above fd.o bug report has been fixed. Is this still a problem?

The problem is still there.