7.52 broke emoji 'soft-keyboard' completely on Linux/BSD?

[gh-ix]

Using a supported version?

• I have searched searched open and closed issues for duplicates.
• I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

Overall summary

Hi,
as title says - after updating to 7.50 there was the already reported bug of terminating emoji selection window after the first selection. It was confirmed and supposed to get fixed 'with the next release'.
The 'next release' I installed is 7.52 now, and indeed - the problem vanished, because now I don't get a emoji selection window at all anymore.

Steps to reproduce

Install version 7.52
Open signal-desktop (Linux/FreeBSD)
Select a chat
Click on the Smiley icon

Expected result

Click on the Smiley icon opens emoji selection window

Actual result

Click on the Smiley icon has no effect at all

Screenshots

No response

Signal version

7.52

Operating system

FreeBSD 14.3

Version of Signal on your phone

7.39.4

Link to debug log

No response

[ayumi-signal]

Hi, sorry about that. I'm not able to reproduce it on Debian with 7.52, the smiley opens the emoji picker as expected. Could you submit a debug log (View -> Debug Log)? also curious how to run FreeBSD, since it's not an officially supported platform at the moment.

[gh-ix]

Sorry for the late reply.
Since source is available, it's even for end users a piece of cake to compile any signal-desktop version for any FreeBSD version, it's just a matter of 'make' - thanks to the FreeBSD ports tree and people maintaining ports and dependencies.

I never had isolated issues before - this time it seems it is FreeBSD specific, since you cannot reproduce on Linux.
Just in case anybody want's to have a look at otherwise unobtrusive logs:
https://debuglogs.org/desktop/7.52.0/c7b5e35de2ddc292f854761e2ccaabddb123e7389522c7d825f9d6e9a33057dd.gz

Thanks!

[gh-ix]

Additional note:
I can "react" with any of the pre-defined emojies, but selecting others via '...'-button is not possible.
As with the emoji icon next to the message composing line at the bottom, clicking the "..." has no effect. No error logged, no response at all.
The "Convert typed emoticons to emoji" setting works too, it's just the selection plane doesn't open.
(built with electron 34.5.3 - like mentioned, if I previously recognized any glitch, it affected at least the Linux versions too)

[scottnonnenberg-signal]

These are the only errors I saw in your log. It seems like larger things are going wrong:

ERROR 2025-05-07T12:31:59.020Z MainSQL: Database startup error: Error: sqlite error(7): out of memory
ERROR 2025-05-07T12:31:59.020Z Failed to get zoom factor {"name":"Error"}
ERROR 2025-05-07T12:32:00.168Z sql.initialize was unsuccessful; returning early
ERROR 2025-05-07T12:32:00.169Z Top-level unhandled promise rejection: TypeError: Cannot destructure property 'getIsInCall' of 'window.Events' as it is undefined.
ERROR 2025-05-07T12:32:03.888Z onDatabaseError: Quitting application
ERROR 2025-05-07T12:32:03.890Z Error occurred in handler for 'sql-channel:read': {"name":"Error"}

Perhaps we close this in favor of this bug?

[gh-ix]

Everything is working fine but the emoji selection pane.
Neither any memory shortage on RAM nor HD, nor any other malfunctions, despite that strange sqlite error log.
Maybe emojies are indexed in sqlite? Maybe the db backing file is corrupt or the return code is misleading? No idea, I'm far too unfamiliar with any aspect of electron apps to help debugging here, sorry.

[major-mayer]

While we are at it, I noticed that some recent update has introduced a new, IMO very annoying behaviour of the emoji picker.
For me, the emoji picker opens just fine (Signal 7.53 on Linux), but when you select an emoji using the mouse pointer, the text input field actually looses focus.
This means that while emoji picker is not manually closed, it is not possible to press "Enter" to send the message.

Instead, if you press Enter, the emoji is inserted a second time, and, even worse, when you press Enter a second time the emoji is not inserted a third time, but instead this time the message is actually sent 😟
I've ended a lot of messages with duplicate emojis because of this.

I would expect that selecting an emoji in the picker, doesn't move the focus away from the input box, because TBH who selects an emoji using the keyboard, after opening the picker with the mouse?
At least the folks at WhatsApp don't think that's common, and IIRC Signal did so too back then.

Could this UX change be reverted?

[MikaelUrankar]

It's broken with 500ef09

[MikaelUrankar]

This patch works but I don't understand why it's needed on FreeBSD:

--- ts/components/fun/isFunPickerEnabled.tsx.orig	2025-05-26 15:01:58 UTC
+++ ts/components/fun/isFunPickerEnabled.tsx
@@ -3,5 +3,5 @@ export function isFunPickerEnabled(): boolean {
 import * as RemoteConfig from '../../RemoteConfig';
 
 export function isFunPickerEnabled(): boolean {
-  return RemoteConfig.isEnabled('desktop.funPicker');
+  return RemoteConfig.isEnabled('desktop.funPicker.prod');
 }```

[cullumsmith]

I can confirm the same issue and can also confirm that @MikaelUrankar's patch fixes it for me.

I filed an issue against the FreeBSD ports tree here.

[cullumsmith]

This issue appears to be fixed in 7.54.