Bug 59104

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).