1

Clicking a link in Thunderbird or Libre Office Writer opens a new instance of Firefox with my home page and not the required URL.

My home page always opens, whether I use left-click, ctrl+left-click or middle click (open link in new tab) in Thunderbird; or ctrl+left-click or Open hyperlink from the Libre context menu.

To open an external link, I have to select Copy link location from the Thunderbird context menu, then paste the URL into Firefox. In Libre, I have to manually copy the URL.

Can anyone help me to fix this problem?

There are many similar questions, but they seem to be very old and relate to obsolete versions.

I am using Linux Mint Cinnamon 21.1 with the latest versions of Firefox and Thunderbird. Libre Office is 7.3.7.2. The problem is not version-specific (it used to happen when I ran Firejail, but I removed Firejail partly because of similar problems). Firefox is my default (and only) browser.

Edit - in answer to #harrymc comment

It's a new computer, this year. A new SSD, Linux, etc. Personal settings and data were restored from a backup. https://support.mozilla.org/en-US/kb/back-and-restore-information-firefox-profiles describes the process - if I have read it correctly, any corruption from the old profile would get copied over. I am not about to create a new virgin profile and loose all my bookmarks, passwords, etc.

3
  • Something perhaps went wrong in the settings of Firefox. It might be simpler to uninstall it, clean up all its folders and reinstall.
    – harrymc
    Commented Jun 30, 2023 at 10:28
  • What Linux distribution and Desktop Environment are in use? An example bug that has similar behaviour described is here: bugzilla.mozilla.org/show_bug.cgi?id=1138143. If you restored from backup, and the backup includes an old .desktop file, then perhaps it has a problematic configuration that's causing Firefox to not open the URL. Running strace xdg-open "https://openstreetmap.org" 2>&1 | grep -i "desktop" may provide hints as to which/where .desktop file is being opened (depending on the distribution). Commented Jul 5, 2023 at 22:37
  • @PrestonManess, thanks, you have put me on the right track and you deserve the credit. Please read my answer and consider posting your own answer.
    – Peter bill
    Commented Jul 8, 2023 at 15:13

2 Answers 2

0

Original answer from comment:

If you restored from backup, and the backup includes an old .desktop file, then perhaps it has a problematic or outdated configuration that's causing Firefox to not open the URL. Running strace xdg-open "https://openstreetmap.org" 2>&1 | grep -i "desktop" may provide hints as to which/where .desktop file is being opened (depending on the distribution).

Updates:

As per your answer, you did manage to find a .desktop file at ~/.local/share/applications/firefox.desktop, and removing it did fix the problem, so odds are good that the link opener/handler was referencing that file and it had an issue. And as for why the command I offered returned no results, it may be the case that Linux Mint Cinnamon does not use the XDG standards when handling links. Or it could also be the case that xdg-open and/or strace isn't on the system. In which case the command wouldn't work, but also wouldn't output anything since stderr is getting redirected to stdout and then grepped. Serves me right for erroneously assuming the commands are installed everywhere and suppressing stderr :P

1
  • I have both xdg-open and strace installed. I tried the strace command without the redirections and grep - there was no mention of any desktop file, but there was an Invalid Argument error, with no detail. Much of the output was beyond my comprehension.
    – Peter bill
    Commented Jul 9, 2023 at 13:40
0

After the comment by @prestonmaness, I investigated my .desktop files.

First the good news: Removing the file ./.local/share/applications/firefox.desktop cured the problem. There don't seem to be any adverse effects.

Other analyses:

The command strace xdg-open "https://openstreetmap.org" 2>&1 | grep -i "desktop" showed no output.

The .desktop file showed no obvious corruption. It contained no -remote arguments.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .