Bug 96472 - xdg-open opens magnet links in the browser instead of the default bittorrent application (suggested patch)
Summary: xdg-open opens magnet links in the browser instead of the default bittorrent ...
Status: REOPENED
Alias: None
Product: Portland
Classification: Unclassified
Component: xdg-utils (show other bugs)
Version: 1.1.0
Hardware: All Linux (All)
: medium normal
Assignee: Rex Dieter
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 101640
  Show dependency treegraph
 
Reported: 2016-06-10 05:12 UTC by cyrozap
Modified: 2018-03-31 20:55 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch to fix the x-scheme open issue. (301 bytes, patch)
2016-06-10 05:12 UTC, cyrozap
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description cyrozap 2016-06-10 05:12:56 UTC
Created attachment 124435 [details] [review]
Patch to fix the x-scheme open issue.

I'm using version 1.1.1 on Arch Linux, but that wasn't available in the drop-down so I chose the closest version.


Expected behavior:

Opening a magnet link with xdg-open will open that link in the default bittorrent application.


Actual behavior:

Opening a magnet link with xdg-open opens the link with the browser set by $BROWSER.


Steps to reproduce:

1. Set the BROWSER environment variable to any browser.
2. Run `xdg-open magnet:?xt=foo`.
3. The magnet link will be opened by the browser instead of the default application for magnet links.


I first noticed this issue when clicking a magnet link in Chromium/Chrome would open a new tab. Since Chromium uses xdg-open, I first checked to make sure `xdg-mime query default x-scheme-handler/magnet` returned my default torrent application. Since xdg-mime reported the correct default application, I looked in xdg-open to see why it was opening my browser instead. I managed to find the problem code here:

...
817     if [ -n "$BROWSER" ]; then
818         open_envvar "$1"
819     fi
820 
821     if [ -n "$DISPLAY" ]; then
822         open_generic_xdg_x_scheme_handler "$1"
823     fi
824 
825     # if BROWSER variable is not set, check some well known browsers instead
826     if [ x"$BROWSER" = x"" ]; then
827         BROWSER=www-browser:links2:elinks:links:lynx:w3m
828         if [ -n "$DISPLAY" ]; then
829             BROWSER=x-www-browser:firefox:iceweasel:seamonkey:mozilla:epiphany:konqueror:chromium-browser:google-chrome:$BROWSER
830         fi
831     fi
832 
833     open_envvar "$1"
834 
835     exit_failure_operation_impossible "no method available for opening '$1'"
...

Since $BROWSER is defined in my .bashrc, the first code path (`open_envvar "$1"`) and `open_generic_xdg_x_scheme_handler "$1"` is never reached. To fix this, I removed lines 817-819. Since the `open_envvar "$1"` will happen eventually if $DISPLAY is not set, this shouldn't drastically change how this piece of code works.

For convenience, I've attached the patch I made to this message.
Comment 1 Rex Dieter 2016-06-10 12:25:03 UTC
yeah, the 'open in a browser' last-ditch fallback probably needs to go away, but these patch only partially removes it, so not good enough.

I think I'll just bump it's prority down, so that open_generic_xdg_x_scheme_handler comes before.
Comment 3 Nicholas Guriev 2017-09-30 12:51:30 UTC
Hi,

That commit breaks an autotest for xdg-open. The test case is named "always uses $BROWSER if set in generic mode". So I think you "patched" an intended behaviour. Or that test should be rewritten.
Comment 4 Nicholas Guriev 2017-09-30 19:04:12 UTC
Well, I'm reopening the bug because this situation needs to be solved.
Comment 5 Rex Dieter 2017-10-09 18:12:03 UTC
"always uses $BROWSER if set in generic mode" is definitely not ideal now, that test's assumptions are now indeed invalid.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.