1844959 - Implement GTK Emoji Chooser

Status: RESOLVED FIXED

(Core :: Widget: Gtk, enhancement, P3)

Description

[Christoph Anton Mitterer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

GTK supports a native Emoji Chooser, which should already work with GTK 3 used by Firefox (on Linux) and is activated by pressing Ctrl-. or Ctrl-; .

Expected results:

Given that Emojis are used quite often when entering text on websites, it would be nice if Firefox could enable support for that.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

I guess it would be similar to GtkFileDialog implementation:
https://searchfox.org/mozilla-central/source/widget/gtk/nsFilePicker.cpp

It's implemented by GtkEmojiChooser widget.

Comment 3

[David Flanagan]

On Firefox Nightly, currently 129.0a1 (2024-07-02) (64-bit), pressing control+. for the GTK emoji picker renders Firefox unusable.

It doesn't crash, but everything grinds to a complete halt until killed.

Comment 4

[Martin Stránský [:stransky] (ni? me)]

The problem is that we create the emoji widget as a child of hidden GtkEntry and not the visible one.

Comment 8

[Martin Stránský [:stransky] (ni? me)]

Explicit emoji popover is available in Gtk4. Unfortunately the widget is not exported in gtk3. We'd need to pass correct widget to it but I'm not sure how to handle the emoji position for the GtkWindow.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Looked at it and there are two issues here. First the popup is popover type and after CTRL+. is invoked but struck in waiting-to-show state. Perhaps due to hidden parent GtkEntry widget. But we may take Gtk3 widget implementation and ship that as embedded widget. But we don't have exact location where the widget may be placed - we use only one nsWindow and GtkEntry is used for key binding only.

Comment 10

[Martin Stránský [:stransky] (ni? me)]

I expected Gtk4 may help here but it can't - the main issue is popup placement which we need to solve.

Comment 11

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1844959 [Linux] Add emoji picker support r?emilio

Comment 12

[Martin Stránský [:stransky] (ni? me)]

There's a WIP which created keybinding entry as child of mozcontainer which tricks Gtk to show it as a child of nsWindow which makes it visible after CTRL+. But it doesn't insert the selected emoji to entry and also needs to be placed according to focused field.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

Emilio, do you know if we can get position of input field (if that's active?) on widget? I guess we'd need to load it from layout or so?
Thanks.

Comment 14

[Emilio Cobos Álvarez [:emilio]]

Can you add the emoji picker as a child of mShell rather than mContainer? That seems like it would work just as well and probably be simpler, right? But yeah, to your question, we have two kinds of precedent for this, I think:

• The IME popup.
• The context menu shortcut (Shift + F10).

I think this should work similarly to one of the two.

Right now the context menu key event goes through the whole event system, maybe this would be more similar to an IME feature, specially since we only care about this for composition?

Maybe Masayuki has thoughts on which approach might work better?

Comment 15

[Martin Stránský [:stransky] (ni? me)]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #14)

Can you add the emoji picker as a child of mShell rather than mContainer? That seems like it would work just as well and probably be simpler, right?

AFIAK mShell is GtkWindow and it implements GtkBin which allows to hold only one child.

But yeah, to your question, we have two kinds of precedent for this, I think:

• The IME popup.

Do you know how the IME popup is issued?

• The context menu shortcut (Shift + F10).

That popup looks great!

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think the picker should be around the caret. If so, you can get the position with a query content event like this:
https://searchfox.org/firefox-main/rev/133582f487ff8291ec10bd524db52db0b8ed363e/widget/gtk/IMContextWrapper.cpp#2970-3009

And you can get current caret offset in the flattened text content in the editor with:
https://searchfox.org/firefox-main/rev/133582f487ff8291ec10bd524db52db0b8ed363e/widget/gtk/IMContextWrapper.cpp#3315-3326

Comment 17

[Martin Stránský [:stransky] (ni? me)]

Thanks, the patch here works somehow but throws various Gtk related warnings due to GtkEntry put to more containers. I think we may use general GtkEntry/TextView for binding and if the emoji chooser is issues, we may create and put dedicated widgets to focused nsWindow.

That solution ensures we don't create redundant widgets.

Comment 18

[Martin Stránský [:stransky] (ni? me)]

The patch above works but needs to fix one last thing - when emoji picker is selected we hide cursor. The emoji picker is considered as cursor input and we hide cursor for it. Unfortunately emoji picker doesn't have a signal when emoji is not selected - only when it's picked - so I need to find a way how to restore 'hide cursor' state when emoji is not selected.

Comment 19

[Martin Stránský [:stransky] (ni? me)]

We may also add a pref to disable it as it may break some scenarios.

Comment 20

[Martin Stránský [:stransky] (ni? me)]

The patch here implements emoji for toplevel windows only. We may consider to add support for popups too if that's requested.

Comment 21

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1844959 [Linux] Add widget.gtk.native-emoji-dialog preference r?emilio

Comment 22

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1844959 [Linux] Support Emoji picker on popups r?emilio

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/028532759f45
https://hg.mozilla.org/integration/autoland/rev/1b2b2111d8b5
[Linux] Add emoji picker support r=emilio
https://github.com/mozilla-firefox/firefox/commit/b1d3b9c98588
https://hg.mozilla.org/integration/autoland/rev/8dc6b197b435
[Linux] Add widget.gtk.native-emoji-dialog preference r=emilio
https://github.com/mozilla-firefox/firefox/commit/6223daced021
https://hg.mozilla.org/integration/autoland/rev/53ae743699cd
[Linux] Support Emoji picker on popups r=emilio

Comment 24

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/1b2b2111d8b5
https://hg.mozilla.org/mozilla-central/rev/8dc6b197b435
https://hg.mozilla.org/mozilla-central/rev/53ae743699cd

Comment 26

[Donal Meehan [:dmeehan]]

:stransky, could you consider nominating this for a release note? (Process info)

Comment 27

[Martin Stránský [:stransky] (ni? me)]

Release Note Request (optional, but appreciated)
[Why is this notable]: Implements Gtk Emoji picker dialog, allows to insert emoji when Gtk key binding is activated (usually CRTL+.)
[Affects Firefox for Android]: none
[Suggested wording]:
[Links (documentation, blog post, etc)]:

Comment 28

[Donal Meehan [:dmeehan]]

Thanks, added to the Fx150 nightly release notes, please allow 30 minutes for the site to update.

Comment 29

[Christoph Anton Mitterer]

150 just hit Debian unstable,... while the chooser works in principle. I do see some weird graphic effects every time it appears and disappears, in particular, over the whole size of the chooser widget the background image "shines" through.

May of course be an issue in X, GTK, or Cinnamon's composer,... but at least no such thing would happen with other programs that do support the emoji chooser (like gedit).

Also it seems, that the first time on a window that I make the chooser pop up, it's not only the background that shows through but there's some "flickering" effect. But this is gone when I do it again on the same window (even if it's on another tab of that, as far as I can see).

Comment 30

[Martin Stránský [:stransky] (ni? me)]

Yes, that's correct - and it's due to the fuzzy implementation where custom and X11 rendering is mixed. Only 'fix' is to disable it on X11 but I think it's still worth regardless of the flickering (or we can disable the pref by default on X11 and leave users to turn it on).

Comment 31

[Christoph Anton Mitterer]

Ah I see. Well please leave it, better that than nothing and X is anyway slowly on it's way out.

I'd even say don't disable it per default. Those people who use it most likely want it, those who don't aren't affected by that graphics glitches anyway.