0

Whenever I click on a hyperlink presented within a software the link seems to be modified. Let's say software X presents a link to its online documentation, e.g. https://www.coolsoft.org/doc/manual.html

I get an error message in a window marked with a yellow folder in the upper left. The error message will read:

/home/myuser/'somepath'/http:/www.coolsoft.org/doc/manual.html: file or directory not found

'somepath' seems to be the working directory of program X in many cases. Note that the full link which is obviously nonsense misses a / after http: or https: The small folder symbol in the corner of the error message makes me think, that the issue is related to lxde's file browser.

However there are exceptions. When I click links in messages in Thunderbird, the link opens flawlessly in firefox.

How can I fix this?

Update

Being asked for a specific example. Today I used Anki. Anki was installed via packet manager (xbps). Anki showed a link with information to look up. It triggers the error message:

/home/ariser/.local/share/Anki2/Benutzer 1/collection.media/http:/ankisrs.net/docs/manual.html#using-decks-appropriately: Datei oder Verzeichnis nicht gefunden

This is the original error message in German.

Ariser
  • 213
  • hm, interesting! Since this might be happening on the boundary of specific programs and your specific session manager LXDE, it'd probably be easiest to talk about a specific example that actually triggers this behaviour – so far we only know one that does not! So, picking any one, in which program does this happen? – Marcus Müller Jun 28 '22 at 20:30
  • Do you get the same error with correctly formed URLs? I.e., with URLs that have http:// (double slash) instead of http:/ (single slash). – Kusalananda Jun 28 '22 at 21:11
  • @Kusalananda I can't test it with correctly formed URLs because all URLs from any program get mangled this way. Just for testing I opened FreeCAD and tried to open the homepage via the help menu of the program and the URL is crippled again: /home/ariser/http:/www.freecadweb.org I don't think it's the fault of the programs supplying the URL. – Ariser Jun 29 '22 at 05:23
  • Wow, interesting... Does running xdg-open https://example.com also fail? – Marcus Müller Jun 29 '22 at 23:55
  • My current guess is that something installed a URL handler for http:, which was maybe designed to handle a few http URLs itself and pass through the rest to a browser, and that thing is badly broken – Marcus Müller Jun 30 '22 at 07:36
  • @MarcusMüller Yes xdg-open results the same way. And again miraculously one of the slashes removed. i.e. xdg-open https://www.tagesschau.de brings up /home/ariser/https:/www.tagesschau.de: Datei oder Verzeichnis nicht gefunden Funny. – Ariser Jun 30 '22 at 13:20
  • wow! OK, then, who does this? What does xdg-settings get default-url-scheme-handler https say? – Marcus Müller Jun 30 '22 at 14:21
  • @MarcusMüller userapp-Firefox-VHCIT0.desktop – Ariser Jul 03 '22 at 16:07
  • 1
    now, I don't know void linux (this is void Linux, right?) well enough, but for me that's just firefox.desktop, which means /usr/share/applications/firefox.desktop is consulted on how to open https URLs, which in turn just runs firefox %u (the %u gets replaced with the URL). Do you have a firefox.desktop containing an Exec=firefox %u line? Can you try to locate userapp-Firefox-VHCIT0.desktop, and check whether it does something strange in the Exec= line? – Marcus Müller Jul 03 '22 at 16:22
  • @MarcusMüller mlocate yields /home/ariser/.local/share/applications/userapp-Firefox-VHCIT0.desktop and within that I found Exec=/usr/lib/firefox/firefox %u So nothing which could explain why the URL gets mutilated. I think the error message could be issued by PCManFM. Perhaps the URL is not recognized as URL at all but gets interpreted as a local path from the very beginning. – Ariser Jul 04 '22 at 15:14
  • @Ariser I considered that possibility, that's why we ruled it out through xdg-open https://example.com! Now we're down to debugging where the hell things go wrong, in the source code (I'm so here for this kind of bug hunting!) – Marcus Müller Jul 04 '22 at 15:19
  • 1
    @Ariser 1. /usr/lib/firefox/firefox https://example.com does work, right? (I really think it ought, but I've stopped ruling out things!) – Marcus Müller Jul 04 '22 at 15:21
  • 1
  • if it does work, we need to debug xdg-open; if it doesn't, we need to debug that script.
    • – Marcus Müller Jul 04 '22 at 15:27
  • @MarcusMüller firefox is opening the sample domain correctly, xdg-open can't interfere here, at least. That could explains why Thunderbird manages to open URLs in firefox. Thunderbird most likely looks up if FF is installed and calls it directly then :) – Ariser Jul 05 '22 at 12:37