Broken links (when opening external links such as browser links0

Support
1

Operating system

Linux

Joplin version

3.4.10

What issue do you have?

I cannot open any external link under Ubuntu Joplin, even links under Help (for ex. join us on Bluesky) do not function. I tried to check on Ubuntu side, uninstall and reinstalling my default browser, or change it, but this do not help. Btw, my browsers are fully functional under Ubuntu. When I click a link under Joplin,, I get the message "no apps available" no apps installed that can open "null". You can find more apps in software...I checked my browser ability to open html web pages, and it is totally functionnal out of Joplin. So what? I do not find also an option in Joplin to change the default browser to open external links, Can ypu help?

2

Just some general ideas, since the desktop version info is missing:

  • Does it work after reboot?
  • There seems to be a similar issue here. I.e. at the first step, check if the output of xdg-mime query default x-scheme-handler/https is your browser.
  • How did you install Joplin? (Appimage, Flatpak, Snap)
3

Hi, thank you for this quick return.

I reboot a lot of times, (also for other reasons), but did not solve.

I have Joplin under Ubuntu, for years (3 or 4?), worked fine till this problem. I think it was installed using snap at that time.

I forgot to say, if I copy paste any link in Joplin in any browser, it tworks fine.

Good day.

4

Can you please try

snap run --shell joplin-desktop
> xdg-open https://google.com

And let me know what happens, also, are you this guy?

I did change some stuff relating to this functionality last week, but it doesn’t look like my side of the code is failing to work at all, but instead the associativity rules of the XDG Desktop Portals is failing to find anything valid handling http: or https:protocols on the system. It wasn’t even a code change, it was a Dbus dependency bump!

Often just swapping the default in the system defaults will be enough to update these rules in the backend, but I am just concerned why it keeps getting unable to open “null” specifically, which is why calling the binary directly might help.

Null isn’t even a valid concept here. The code checks the argc count and spaces aren’t valid, I’m not sure how xdg-open is getting a null at all, making me think it’s outside the snap itself.

5

FWIW since this was reported elsewhere and does appear to be fairly systemic, I’m hoping to release a fix for the snap in the next hour.

6

Hi, I add an actualization of Ubuntu to day, dont know if this was the case but now the external links in Joplin are working fine.

(before, I tried all the proposals you sent including the ones in the link here (…there seems to be a similar issue here) but they did not solve.

Anyhow, thank you again for your quick help an dedication to my problem.

Btw, I am not Laurent!

7

Sorry for that, the underlying problem was specific to revisions 115 and 116 of the snap due to a dependency bump on a custom tool that replaces xdg-open with some custom logic to help in niche scenarios. The dependency was reverted and revisions 117 and 118 fixed it. They were then replaced in under an hour with 119 and 120 since I’d noticed 3.4.12 released too. That tool doesn’t get used anywhere else in the world, and only exists to try ease sandbox issues by controlling the XDG Desktop Portals directly (for super nerds, its the writable=true aspect on the org.freedesktop.portal.OpenURI.OpenFile API).

Unfortunately any similar problems are completely unrelated, the only fix is to not be on that snap revision because the snap itself is the problem not the system. Automatic updates will sort that out promptly for most. :slight_smile:

Since revisions are awkward for users to deal with, it’s probably easier to say it’s fixed in 3.4.12, but was only ever a downstream issue, just timing wise, both the fix and 3.4.12 were pushed the same day.

Still, glad to see it’s working again! :slight_smile: