Change:
in lib.optionalString (spellcheckerLanguage != null) '' --set HUNSPELL_DICTIONARIES "${hunspellDicts.${hunspellDict}}/share/hunspell"  --set LC_MESSAGES "${spellcheckerLanguage}"''); <ins> sqlcipher-signal = sqlcipher.overrideAttrs (_: { # Using the same features as the upstream signal sqlcipher build # https://github.com/signalapp/better-sqlite3/blob/2fa02d2484e9f9a10df5ac7ea4617fb2dff30006/deps/defines.gypi CFLAGS = [ "-DSQLITE_LIKE_DOESNT_MATCH_BLOBS" "-DSQLITE_THREADSAFE=2" "-DSQLITE_USE_URI=0" "-DSQLITE_DEFAULT_MEMSTATUS=0" "-DSQLITE_OMIT_DEPRECATED" "-DSQLITE_OMIT_GET_TABLE" "-DSQLITE_OMIT_TCL_VARIABLE" "-DSQLITE_OMIT_PROGRESS_CALLBACK" "-DSQLITE_OMIT_SHARED_CACHE" "-DSQLITE_TRACE_SIZE_LIMIT=32" "-DSQLITE_DEFAULT_CACHE_SIZE=-16000" "-DSQLITE_DEFAULT_FOREIGN_KEYS=1" "-DSQLITE_DEFAULT_WAL_SYNCHRONOUS=1" "-DSQLITE_ENABLE_COLUMN_METADATA" "-DSQLITE_ENABLE_UPDATE_DELETE_LIMIT" "-DSQLITE_ENABLE_STAT4" "-DSQLITE_ENABLE_FTS5" "-DSQLITE_ENABLE_JSON1" "-DSQLITE_ENABLE_RTREE" "-DSQLITE_INTROSPECTION_PRAGMAS" # SQLCipher-specific options "-DSQLITE_HAS_CODEC" "-DSQLITE_TEMP_STORE=2" "-DSQLITE_SECURE_DELETE" ]; LDFLAGS = [ "-lm" ]; }); </ins> in stdenv.mkDerivation rec { pname = "signal-desktop"; version = "5.19.0"; # Please backport all updates to the stable channel.

Discussion:
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 , however, I have checked that the packages between Firefox and Signal are the same, using as described in the wiki article regarding the Discord issue (notably, Discord is also correctly using the same 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: from the channel to click a link to open it in the browser 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 experimental backend and with the "stable" X backend through XWayland; the result is the same. Using the sway window manager. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
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).
I understand. Maybe some other users will have encountered this issue, though it isn't particularly major or a dealbreaker, more of an annoyance.
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.
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 has the same underlying cause.
Just confirmed it and Element suffers from the same issue if run through XWayland, with the 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.
I have the same error "Firefox is already running but is not responding" for Slack trying to open a link. Slack runs thru XWayland.
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 variable, I'm using ) This did not change anything, though. Links still aren't being opened upon clicking on them.
The underlying cause seems to be , which should get fix in Do you still get this error if you add to your environment? edit: wrong link to pr.
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.
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.
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. 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.
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).
I've tried to debug this issue using strace. On my machine, this seems to be caused by , as will fail to execute because the will be propagated to the call to open the browser.
If preloading SQLCipher is the issue (which sounds reasonable) then the easiest solution might be to wrap for Signal-Desktop and either unset or remove SQLCipher it. Would be nice if upstream would offer a way to avoid this entire SQLCipher vs.

SQLite mess...
I checked with the newest commit from nixos-unstable (running signal-desktop version is ) and sadly clicking links still doesn't open them in Firefox for me (trying with , version and version ). Anything I could do to help debug this or should I rather open a new issue?
Apparently this is somehow caused by . When an Electron app launches Firefox via the environment has: GDKBACKEND=x11 Unsetting that by having script like: in so that it’ll be found before the real firefox binary/wrapper fixes the issue for me. I also have set. As to how to properly fix this, I am not sure. Unsetting in the Firefox wrapper would be too intrusive, I imagine?
I started a discussion on a more thorough fix for issues with xdg-open in nixos here