Bug 96472

Summary: xdg-open opens magnet links in the browser instead of the default bittorrent application (suggested patch)
Product: Portland Reporter: cyrozap
Component: xdg-utilsAssignee: Rex Dieter <rdieter>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: boojum, guriev-ns
Version: 1.1.0   
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 101640    
Attachments: Patch to fix the x-scheme open issue.

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.
Comment 6 GitLab Migration User 2019-02-16 13:37:20 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/xdg-utils/issues/88.

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.