As I understand it, the intended way to choose the preferred browser in a "generic" desktop environment is to set the environment variable $BROWSER. But when running xdg-open on a URL in such an environment, it will use whatever browser comes first when searching for desktop files with "x-scheme-handler/http" among the MimeType:s. $BROWSER is only taken into account if no such desktop file exists. I would have thought the call to open_generic_xdg_x_scheme_handler() in open_generic() in xdg-open ought to come AFTER the "for browser in $BROWSER" loop. When testing on my Fedora box with xdg-utils-1.1.0-0.14.20120809git.fc18.noarch, if I open a URL with xdg-open, it comes up in epiphany. Both epiphany.desktop and firefox.desktop lists "x-scheme-handler/http", and since "e" comes before "f", epiphany wins. I have $BROWSER set to "firefox", but that is apparently ignored.
I think I'd rather keep behavior as: 1. Follow "standards-based" methods to find default app 2. only resort to legacy hacks (e.g $BROWSER) when 1 fails
I see. I'll go back to the documentation to read up on what the standards based method to select a preferred browser in a "generic" environment is. I thought it WAS $BROWSER, but I take it from your comment I was wrong.
See, xdg-settings --manual for example(s) of how to set/query default webbrowser
Unfortunately, xdg-settings doesn't seem to work at all in a "generic" setting. Whatever I try, I get the same error message freddi$ xdg-settings get default-web-browser xdg-settings: unknown desktop environment freddi$ xdg-settings set default-web-browser firefox.desktop xdg-settings: unknown desktop environment There is a "generic" case at the end of the file, but there isn't, as far as I can see, any way for $DE to become "generic". Maybe this should be files as a separate bug?
Looking a bit further in xdg-settings, the top of dispatch_generic() shows setting not to be supported anyway: # We only know how to get or check the default web browser. [ x"$op" != x"get" -a x"$op" != x"check" ] && exit_failure_operation_impossible On the other hand, reading the xdg-mime code a bit more, I figured out, though, that I could create a .local/share/applications/mimeapps.list file where I can declare my preferences. I did so using a regular editor, and now xdg-open does use firefox for http again.
OK good to see this issue is already filed. I support the original claim that if ${BROWSER} is defined, it should be preferred to system mime setup. This is based on reasoning that if ${BROWSER} is defined, it's there for some reason and user wants it to be so. In my workflow, when I launch a secondary X server DISPLAY=:1 on my localhost for a "comes and goes" USB display, I still want my http link handling take place on DISPLAY=:0, or laptop screen. This is easily achieved by doing BROWSER="firefox-display-0" which is a simple oneliner shell script "DISPLAY=:0 firefox-bin $@". But xdg-open ignores it and therefore launches a new copy of firefox on DISPLAY=:1, where of course I cannot use my main web browsing profile which is in use and locked on DISPLAY:=0. Basically I would have to create some random invalid value in my local mimeapps.list to make xdg-open fail the .desktop file search and fall back to $BROWSER. I think that makes less sense from a system integrity standpoint than what xdg-open implements now - intentionally making things fail to achieve what you need just doesn't sound right. Is there something I'm missing in my logic above? Can xdg-open still be convinced to change its behavior?
Well, I guess: $ cp /usr/share/applications/firefox-bin.desktop ~/.local/share/applications And doing: Exec=env DISPLAY=:0 /usr/bin/firefox-bin %U is a decent enough workaround.
This bug has been fixed in the latest version (1.1.0).
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.