signal-desktop cannot open links in the browser

[jmc-figueira]

Describe the bug
In the latest version (5.3.0) and at least since 5.2.1, I cannot open links in Firefox by clicking them.

This is similar to #78961, however, I have checked that the nss packages between Firefox and Signal are the same, using nix path-info $(which signal-desktop) -r | grep nss- as described in the wiki article regarding the Discord issue (notably, Discord is also correctly using the same nss package and links open properly).

At first I thought it might have been due to using the experimental Wayland support, which also breaks non-text copying and pasting (images, for instance), but running Signal through XWayland results in the same issue.

To Reproduce
Steps to reproduce the behavior:

1. Install signal-desktop from the unstable channel
2. Try to click a link to open it in the browser
3. The link does not open in the browser

Expected behavior
The link should open in the browser

Screenshots
N/A

Additional context
Running on NixOS 21.11 (unstable), both with the --enable-features=UseOzonePlatform --ozone-platform=wayland experimental backend and with the "stable" X backend through XWayland; the result is the same.

Using the sway window manager.

Notify maintainers
@primeos

Metadata

• system: "x86_64-linux"
• host os: Linux 5.11.21, NixOS, 21.11pre292520.540dccb2aea (Porcupine)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.4pre20210503_6d2553a
• channels(root): "nixos-21.11pre292520.540dccb2aea, home-manager"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: <nixpkgs/pkgs/applications/networking/instant-messengers/signal-desktop/default.nix>
# a list of nixos modules affected by the problem
module:

[primeos]

I'm not using that feature and cannot easily test it for other reasons so unfortunately I cannot really help you with this (just as a FYI).

[jmc-figueira]

I understand. Maybe some other users will have encountered this issue, though it isn't particularly major or a dealbreaker, more of an annoyance.

[andresilva]

I am having the same issue, can't really tell on which version it started happening as I'm not able to rollback due to Signal database upgrade. I am using Xorg so this issue is not specific to Wayland, I also think the issue isn't specific to Firefox as setting Chromium as my default browser didn't fix the problem either.

[deviant]

I'm having this issue too. It started happening in all the electron-based applications I use (VS Code, Signal Desktop, and also Matrix Element when I tried that out). It's got to be a fairly recent change, maybe within the last two or three weeks. I assume #120228 has the same underlying cause.

[jmc-figueira]

I'm having this issue too. It started happening in all the electron-based applications I use (VS Code, Signal Desktop, and also Matrix Element when I tried that out). It's got to be a fairly recent change, maybe within the last two or three weeks. I assume #120228 has the same underlying cause.

Just confirmed it and Element suffers from the same issue if run through XWayland, with the added detail that I get a "Firefox is already running but is not responding" error when attempting to open any link. Opening links works without issue in Element if using the experimental Wayland/Ozone backend.

Additionally, like originally mentioned, I am also running Discord through XWayland (since it does not yet use Electron >=12, required for Wayland support) and links also open correctly there, which makes it more puzzling, even.

[Congee]

I have the same error "Firefox is already running but is not responding" for Slack trying to open a link. Slack runs thru XWayland.

[andresilva]

Would any of you mind confirming if you can replicate the issue with another browser, e.g. by setting Chromium as default browser temporarily.

[dpaetzel]

Would any of you mind confirming if you can replicate the issue with another browser, e.g. by setting Chromium as default browser temporarily.

I did that by doing (the first line removes the BROWSER variable, I'm using fish)

set -e BROWSER
xdg-settings set default-web-browser google-chrome.desktop
signal-desktop

This did not change anything, though. Links still aren't being opened upon clicking on them.

[jpas]

The underlying cause seems to be electron/electron#28436, which should get fix in electron/electron#29606.

@jmc-figueira

I get a "Firefox is already running but is not responding" error when attempting to open any link.

Do you still get this error if you add MOZ_DBUS_REMOTE=1 to your environment?

edit: wrong link to pr.

[jmc-figueira]

@jmc-figueira

I get a "Firefox is already running but is not responding" error when attempting to open any link.

Do you still get this error if you add MOZ_DBUS_REMOTE=1 to your environment?

Yes, that does fix it, I found out about that environment variable later. But it only solves the issue for Element in XWayland, mind you, the Signal issue is as you said.

[andresilva]

The underlying cause seems to be electron/electron#28436, which should get fix in electron/electron#29606.

@jmc-figueira

I get a "Firefox is already running but is not responding" error when attempting to open any link.

Do you still get this error if you add MOZ_DBUS_REMOTE=1 to your environment?

edit: wrong link to pr.

Isn't this fix specific to Firefox on Wayland? As detailed in previous comments the problem happens with any browser and on X11 as well.

[jpas]

@andresilva

Isn't this fix specific to Firefox on Wayland?

Yes it is specific to Wayland, but it will also fix other GDK interactions such as the file chooser running in xwayland instead of wayland as a side product.

As detailed in previous comments the problem happens with any browser and on X11 as well.

You're right, there's probably a different underlying problem on X11. Which desktop environment or window manager are you using with X11? I'm willing to try and reproduce it.

[andresilva]

I'm using i3, but know someone who has the same issue on KDE (might be easier to reproduce since it's easier to setup).

[TethysSvensson]

I've tried to debug this issue using strace. On my machine, this seems to be caused by #122926, as xdg-open will fail to execute because the LD_PRELOAD will be propagated to the call to open the browser.

[primeos]

If preloading SQLCipher is the issue (which sounds reasonable) then the easiest solution might be to wrap xdg-open for Signal-Desktop and either unset LD_PRELOAD or remove SQLCipher it. Would be nice if upstream would offer a way to avoid this entire SQLCipher vs. SQLite mess...

[teutat3s]

I checked with the newest commit from nixos-unstable (running signal-desktop version is 5.22.0) and sadly clicking links still doesn't open them in Firefox for me (trying with signal-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland, sway version 1.6.1 and firefox version 93.0). Anything I could do to help debug this or should I rather open a new issue?

[liff]

Apparently this is somehow caused by GDK_BACKEND. When an Electron app launches Firefox via xdg-open the environment has:

GDK_BACKEND=x11

Unsetting that by having script like:

#!/bin/sh

exec env -u GDK_BACKEND /run/current-system/sw/bin/firefox "$@"

in PATH so that it’ll be found before the real firefox binary/wrapper fixes the issue for me.

I also have MOZ_ENABLE_WAYLAND=1 set.

As to how to properly fix this, I am not sure. Unsetting GDK_BACKEND in the Firefox wrapper would be too intrusive, I imagine?

[LunNova]

@liff I started a discussion on a more thorough fix for issues with xdg-open in nixos here https://discourse.nixos.org/t/making-xdg-open-more-resilient/16777