Hyperlinks (e.g. in PDFs) open in non-default browser about bunsen-configs HOT 10 CLOSED

Also, I noticed that mimeapps.list contains image/jpeg=bl-image-viewer.desktop, but no entry for image/jpg. Not sure if that has any practical consequences, but xdg-mime query default image/jpg returns mirage.desktop, and not bl-image-viewer.desktop, like the image/jpeg version.

from bunsen-configs.

Hello @tdanhorn, thanks for the feedback.

In reverse order: image/jpeg is the correct mimetype for jpeg images, even if their filename extension is jpg. Some applications do support a hypothetical "image/jpg" mimetype, but there is no need to include it in mimeapps.list in my opinion.

There is no bl-www-browser alternative in fact. The Debian alternative x-www-browser already exists and serves the same purpose.

Choice of the best application to open certain links can be tricky sometimes, though. Have you tried adding entries for x-www-browser to ~/.config/mimeapps.list, and did it fix the issue?

Sometimes, however, a pdf reader might have its own settings for preferred application to open web links.

Another place you can look at is exo-preferred-applications, which sets a few defaults (including web links) for exo-open which is the default BL handler. BunsenLabs default there is Debian Sensible Browser which usually points to x-www-browser, and exo-open <some-url> opens in Firefox for me, though I also have Chromium installed.

It's a complicated topic...

from bunsen-configs.

Hi John,

Thanks for the tips. I am not concerned about jpg, since I have not had any issues with that, so I agree that there may be no need for that.

I did have the issue with hyperlinks opening in chromium, however, until I added the x-scheme-handler lines to /usr/share/applications/mimeapps.list (and I have no doubt adding it to a user-specific version in ~/.config would work as well). exo-open http://example.com on the command line also opens Firefox for me, I suspect it does not use the same mimetype for hyperlinks as atril (my default) or evince (BunsenLabs default, which I also tested). Interestingly xpdf does open the link in Firefox, so it uses a different mechanism or mimetype.

Since Evince is the default PDF viewer in BunsenLabs, I would expect it to honor any setting of the default browser in the distro (whether that is called bl-www-browser, x-www-browser, or sensible-browser). I consider myself fairly tech-savy, but it took me quite some time of web searching and poking around in config files until I found out that I had to set a default for x-scheme-handler/http(s) to be able to get what I would have expected in the first place. (So yes, I agree, it's a complicated topic.) I am not asking for a change in the defaults of BunsenLabs (there are well documented ways I can do that myself, if I wanted to), I just would like it to consistently stick to the ones it already has, and for that adding x-scheme-handler/http(s) lines to one of the mimeapps.list files appears to be necessary (at least I don't know another way). Feel free to set them to x-www-browser or something else; I used bl-www-browser since it exists, works, and appeared to me the "highest level" wrapper (and almost all other entries in mimeapps.list are bl-* applications). I also think the best place to set this is the global mimeapps.list, rather than the user-specific one, since this should be a baseline default (which any user can override).

Thanks for all the great work!

from bunsen-configs.

adding x-scheme-handler/http(s) lines to one of the mimeapps.list files appears to be necessary

Well, as I said, I have both Chromium and Firefox installed, and links in pdf files - in both Atril and Evince - open in Firefox for me, without any such entry in mimeapps.list.

I used bl-www-browser since it exists

bl-www-browser does not exist in a BunsenLabs system. I guess you must have created it.

Anyway, I don't think we need any extra config to get this working for users of the default BL system. I suggest you check exo-open as I mentioned above, and also look into xdg-mime. On my system:

$ xdg-mime query default x-scheme-handler/http
firefox-esr.desktop
$ xdg-mime query default x-scheme-handler/https
firefox-esr.desktop

from bunsen-configs.

Are you talking about a Lithium system? Because I have Hydrogen and Helium, and both have the same issue ... If so, I guess there may be no need for it in Lithium, due to changes in the configuration, although the fact that it works as expected could be coincidence (e.g. order of desktop files in mimeinfo.cache; I have no idea how that is determined, but I would not be inclined to rely on it). What does grep -F x-scheme-handler/http /usr/share/applications/mimeinfo.cache ~/.local/share/applications/mimeinfo.cache show on your system? For me, it is x-scheme-handler/http=chromium.desktop;firefox-esr.desktop; (only exists in the global one).

On Hydrogen xdg-mime query default x-scheme-handler/http (or any other xdg-mime query) returns nothing (some bug?), and on Helium it returns chromium.desktop for me.

Regarding bl-www-browser, there is no executable, but there is /usr/share/applications/bl-www-browser.desktop (which is relevant for the various MIME systems) on both Hydrogen and Helium (and I did not create those). I plan to install Lithium once the next RC ISO is out; until then I can't say what works there.

from bunsen-configs.

Apologies - I had forgotten about the bl-www-browser.desktop file, which was added long ago in order to populate menus with an "X Web Browser" entry, because Debian does not ship an x-www-browser.desktop. (We did not want to clash with a filename which might be added in the future, so used the bl- prefix.)

But my personal system is running BL Helium, and that's what I was referring to as not having the issue you mention.

$ grep -F x-scheme-handler/http /usr/share/applications/mimeinfo.cache ~/.local/share/applications/mimeinfo.cache
/usr/share/applications/mimeinfo.cache:x-scheme-handler/http=firefox-esr.desktop;chromium.desktop;
/usr/share/applications/mimeinfo.cache:x-scheme-handler/https=firefox-esr.desktop;chromium.desktop;

~/.local/share/applications/mimeinfo.cache is empty on my system.
But as you say, the order of entries has no significance and the choice of an application is made elsewhere.

You can change the default xdg-mime app - that might be the source of your issue. See man xdg-mime.

And don't forget to check exo-preferred-applications.

from bunsen-configs.

TL;DR: The reason you get the browser you expect and I don't is not some misconfiguration in my system, but random chance. I think it should not be, so a fix is warranted.

exo-preferred-applications is an XFCE4 thing and in my case points to Debian Sensible Browser, which in turn resolvs to Firefox. I assume it would only affect exo-open anyway, and I have already established that that works as intended.

xdg-mime default is not intended to be run as root, and for regular users it will modify ~/.local/share/applications/mimeapps.list. This file contains no x-scheme-handler lines by default.

Regarding mimeinfo.cache:

But as you say, the order of entries has no significance and the choice of an application is made elsewhere.

The order of lines in that file is irrelevant, but the order of *.desktop entries within each line seems to make all the difference. We both have the same desktop files (firefox-esr.desktop and chromium.desktop) in the x-scheme-handler/http entry, except mine lists chromium.desktop first, and yours firefox-esr.desktop, and the first entry determines which application gets picked in the absence of a default specified by a mimeapps.list file. I have verified that by changing the order in my global mimeinfo.cache file.

From man update-desktop-database (which builds mimeinfo.cache):

The order of the desktop files found for a MIME type is not significant. Therefore, an external mechanism must be used to determine what is the preferred desktop file for a MIME type.

This is not true in the literal sense, as shown above, but I think they it indicates that it is meant to be "not significant", i.e. "Don't rely on mimeinfo.cache, but define the order elsewhere." The problem is that there is no other resolution mechanism for some entries, so the first entry in mimeinfo.cache gets used, and this is arbitrary and possibly quasi-random (I looked at the source of update-desktop-database and it uses hash tables, which makes the choice deterministic, but not easily predictable, and it will be different for most users, as very few have the exact same applications installed) -- the difference between our systems is a good example supporting that.

Since changing the order in mimeinfo.cache manually affects the result, we know that there is no "external mechanism" somewhere else that we might have overlooked, which in turn means we should probably create one (unless we like the browser choice to governed by the luck of the draw in a hash table). The canonical way to do this would be to add appropriate entries to the mimeapps.list file.

from bunsen-configs.

On Hydrogen xdg-mime query default x-scheme-handler/http (or any other xdg-mime query) returns nothing (some bug?), and on Helium it returns chromium.desktop for me.

On my system:

$ xdg-mime query default x-scheme-handler/http
firefox-esr.desktop
$ xdg-mime query default x-scheme-handler/https
firefox-esr.desktop

Different xdg-mime settings between our systems.

You can change the default xdg-mime app - that might be the source of your issue. See man xdg-mime.

Have you tried this?

from bunsen-configs.

Yes:

xdg-mime default is not intended to be run as root, and for regular users it will modify ~/.local/share/applications/mimeapps.list. This file contains no x-scheme-handler lines by default.

The reason I submitted this issue is not to ask for help with "my problem". (It works after I did what I am asking for in the original post.) I found a fix that is general and works for all users on all systems, and I wanted to share it.

from bunsen-configs.

OK, to summarize:
BunsenLabs is a Debian Stable system with certain configurations applied to set up a user environment. We prefer to keep changes from default Debian to a minimum.

The bl-* seeded entries in the ~/.local/share/applications/mimeapps.list that we ship in /usr/share/bunsen/skel are there because they are BunsenLabs inventions that no other developers are aware of. The same is not true of sensible-browser and x-www-browser which have already been set up by Debian.

Since Evince is the default PDF viewer in BunsenLabs, I would expect it to honor any setting of the default browser in the distro

This is expecting too much both of Evince and of a "distro" which is not a full-blown desktop environment like Gnome or KDE. Also, browsers can be quite aggressive in changing default settings when installed.

I don't have time to research this further at the moment, but if you want to get to the bottom of it, I would suggest looking into exactly what helper evince calls when asked to open a url.

https://wiki.debian.org/DefaultWebBrowser

The problem you experienced is not a result of BunsenLabs configuration, but part of the basic Debian system. If it turns out not to be a misconfiguration on your part, then the bug, if there is one, is with one of the Debian utilities, or possibly with evince.

But thank you for your input.

from bunsen-configs.