2060994 - macOS emoji picker does not insert emojis into Twitch chat

Status: REOPENED

(Core :: Widget: Cocoa, defect)

Description

[John]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.6 Safari/605.1.15

Steps to reproduce:

Description:

Whenever I use Firefox on macOS, emojis selected from the macOS emoji picker do not insert into the Twitch chat box.

This problem only occurs in Firefox. In Safari and Chrome, the emoji picker behaves normally and the selected emoji is immediately inserted into the Twitch chat box as expected.

This is a clear Firefox bug and should be investigated and fixed.

Steps to reproduce:

Open Twitch in Firefox.
Click inside the chat box.
Open the macOS emoji picker using the Globe key.
Select any emoji.

Actual results:

Actual result:
The emoji picker opens, but the selected emoji is not inserted into the Twitch chat box.

Expected results:

Expected result:
The selected emoji should be inserted into the Twitch chat box immediately after it is selected.

I would appreciate it if this issue could be fixed as soon as possible. At the moment there seem to be too many bugs and issues like this in Firefox, which is a shame because I believe Firefox is the best browser. If problems such as this are not addressed, I will unfortunately be forced to permanently switch to an alternative browser that works correctly.

System information:

MacBook Pro 16-inch (Apple M1 Pro)
macOS Sonoma 14.6.1
Firefox (Private Browsing mode)

Comment 1

[BugBot [:suhaib / :marco]]

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

Comment 2

[Stephen A Pohl [:spohl]]

This seems to be a duplicate of bug 1926346, which was closed due to a lack of feedback. Would you be able to answer the outstanding question there? In particular, if you pull up the emoji picker with a current nightly using the Fn+e shortcut key, are you able to insert the emoji by pressing the Enter key?

Comment 3

[Stephen A Pohl [:spohl]]

Donal, when I closed bug 1926346 I skipped right over the fact that you said that you were able to reproduce this bug too. Would you be able to answer the question in comment 2? This seems like a quick thing to fix, once I can either repro myself or have someone who might be able to run a test build. Thanks!

Comment 4

[Eric Taylor]

Somehow I missed the request for more info on my bug last year and gave up… it's definitely still active in 153.0.3 and 154.0b8 and 155.0a1 (2026-08-07).

Unsuccessful:

• cmd-ctrl-spacebar, down arrow and return key to select emoji
• cmd-ctrol-spacebar, click emoji

Successful:

• cmd-ctrl-spacebar, use mouse to drag emoji picker out of "local" mode to floating palette, click emoji

Comment 5

[Eric Taylor]

I should add my keyboard doesn't have a "global" key on it, unfortunately so I use cmd-ctrl-spacebar as my shortcut. (Logitech MX Keys S for Mac)

Comment 6

[Donal Meehan [:dmeehan]]

(In reply to Stephen A Pohl from comment #3)

Donal, when I closed bug 1926346 I skipped right over the fact that you said that you were able to reproduce this bug too. Would you be able to answer the question in comment 2? This seems like a quick thing to fix, once I can either repro myself or have someone who might be able to run a test build. Thanks!

Using the Fn+e shortcut key, I am not able to insert the emoji by pressing the Enter key or by mouse-click.

Comment 7

[Stephen A Pohl [:spohl]]

Two things that should help pin down where the emoji is getting lost.

Let's try this as follows:

1. In "about:config", set "intl.ime.use_composition_events_for_insert_text" to "true", then retry on Twitch, and set it back to "false" afterwards.

2. A log would tell us whether macOS hands the emoji to Firefox at all. Quit Firefox, then run the following in Terminal, adjusting the path to the build you tested with:

MOZ_LOG="IMEHandler:5,KeyboardHandler:5,sync,timestamp" MOZ_LOG_FILE=~/Desktop/emoji "/Applications/Firefox Nightly.app/Contents/MacOS/firefox"

Please reproduce it twice in that session, once with the picker anchored to the chat box and once after dragging it out to the floating palette as described in comment 4, so that both attempts are in the same log. Then quit Firefox and attach the "emoji*.moz_log" files from your Desktop. These logs record keyboard and text input activity, so they will contain what you type while Firefox is running.

Comment 8

[Donal Meehan [:dmeehan]]

Attachment: dmeehan.emoji.moz_log

Comment 9

[Eric Taylor]

1. The about:config "intl.ime.use_composition_events_for_insert_text" makes no difference in either state. Interestingly, it was already on on my Nightly? Probably from previous troubleshooting.
2. Attaching file after this… I accidentally did 3 tries:

• cmd-ctrl-spacebar, arrow keys to emojis, enter to select (3x)
• cmd-ctrl-spacebar, mouse click to select (3x)
• cmd-ctrl-spacebar, drag emoji picker into floating palette, mouse to select (3x, and it worked)

Comment 10

[Eric Taylor]

Attachment: emoji.moz_log

Comment 11

[Stephen A Pohl [:spohl]]

A try build with a candidate fix is ready. The fix may or may not catch your case, and the build also carries extra logging, so even if the emoji still does not appear the log should tell us why.

https://firefoxci.taskcluster-artifacts.net/E7pkPJR3T9CeuxoIsT5W3g/0/public/build/target.tar.gz

Let's try this as follows:

1. Download and unpack the archive, then de-quarantine the extracted app:

xattr -dr com.apple.quarantine ~/Downloads/"Firefox Nightly.app"

2. Launch it and check in "about:config" that "intl.ime.use_composition_events_for_insert_text" is set to "false". Eric, yours was still "true" from your earlier troubleshooting, and with it on the candidate fix is not exercised at all.

3. On Twitch, open the emoji picker so that it is anchored to the chat box and select an emoji with a mouse click. Please do that two or three times, then drag the picker out to the floating palette and insert one from there as well, so we have both in the same log.

4. This build writes its own log, so there is nothing to set up beforehand. When you are done, quit Firefox and collect the files:

cp /tmp/emoji-*.moz_log ~/Desktop/

Please attach those and let me know whether the emoji ended up in the chat box.

5. Only if the emoji does get inserted: set "dom.event.insert_text_fallback_to_focused_browser_element" to "false" in "about:config" and try once more. If it stops working with that off, we know that this is what made the difference.

Selecting an emoji with the "Enter" key is expected to still fail in this build. In the logs so far that looks like a separate problem, where macOS appears to hand us nothing at all for that keystroke.

The log records keyboard and text input activity, so it will contain what you type while Firefox is running.

Comment 12

[Eric Taylor]

• Verified first setting false.
• Did test. Weirdly, one got through from the non-floating palette??
• Changed second setting to false.
• More got through from the non-floating palette, but NOT ALL. (Like the laughing cat, for example.)
• Set second setting back to true and quick browser.

Comment 13

[Eric Taylor]

Attachment: emoji-main.43572.moz_log

Comment 14

[Donal Meehan [:dmeehan]]

Attachment: emoji-main.63722.moz_log

I tested several times by clicking the anchored emoji picker, but the emoji never ended up in the chat box.
Afterwards, I used the undocked emoji picker, and the emoji ended up in the chat box.

Comment 15

[Stephen A Pohl [:spohl]]

Both logs cover the parent process only. The cp /tmp/emoji-*.moz_log ~/Desktop/ line should also have copied one or more "emoji-child.<number>.moz_log" files, and those hold the piece that decides this. Could you attach them if they are still around? There is no need to reproduce again.

What the two runs show so far: the emoji reaches Firefox and is handed off to the tab process every time, including all of the attempts where nothing appeared, so whatever drops it sits inside the tab process. Donal, all three of your anchored attempts arrived while Firefox had been told the text field lost focus, and the undocked one arrived while it still had it, which looks like the only difference between them. Eric, yours shows the same pattern less cleanly, since several of your anchored attempts landed anyway, so something else appears to vary as well, most likely timing.

Comment 16

[Eric Taylor]

I regenerated the experiment on my laptop since I'm at work. Unfortunately, I am not seeing anything except the "main" emoji log in the /tmp folder though? I did a search by name for "emoji" and that is the only file that appears.

Comment 17

[Stephen A Pohl [:spohl]]

That was my mistake, but we should be able to work around it for one run by launching the build from Terminal instead of Finder:

MOZ_DISABLE_CONTENT_SANDBOX=1 ~/Downloads/"Firefox Nightly.app"/Contents/MacOS/firefox

Reproduce as before, quit Firefox, then attach both of the files that this lists:

ls /tmp/emoji-*

This turns off the content sandbox for that run, so please quit the build afterwards.

Comment 18

[Eric Taylor]

Attachment: Emoji Logs--et.zip

For some reason, I had like 11 logs generated by this so I made a zip of them all.

Comment 19

[Stephen A Pohl [:spohl]]

Here is a build with a candidate fix. It should stop the anchored picker from dropping emoji, and it carries the same logging as the last one so we can tell what happened either way.

https://firefoxci.taskcluster-artifacts.net/LXzSscvDSy--9i_Mxlvrbg/0/public/build/target.tar.gz

Let's try this as follows:

1. Unpack it and de-quarantine the extracted app:

xattr -dr com.apple.quarantine ~/Downloads/"Firefox Nightly.app"

2. Launch it from Terminal so that the tab process can write its log too:

MOZ_DISABLE_CONTENT_SANDBOX=1 ~/Downloads/"Firefox Nightly.app"/Contents/MacOS/firefox

3. On Twitch, insert a few emoji with the picker anchored to the chat box, then a few more with it dragged out to the floating palette.

4. Quit Firefox and attach everything this lists, both the main and the child files:

ls /tmp/emoji-*

Please also say how many of each attempt landed in the chat box, since that is what we are comparing against the earlier runs.

Eric, if "intl.ime.use_composition_events_for_insert_text" is still "true" in that profile, please set it back to "false" first, otherwise this takes a different path through the code and the fix will not be exercised.

The content sandbox is off for this run, so please quit the build afterwards rather than keeping it open for other browsing.

Comment 20

[Eric Taylor]

Attachment: emoji logs target2--et.zip

You're gonna hate me, but this did not work for me… same results as per usual. Docked picker all emojis fail, undocked all succeed.

Comment 21

[Eric Taylor]

I should add, "intl.ime.use_composition_events_for_insert_text" is verified as false. And I did 3 attempts of docked and undocked.

Comment 22

[Donal Meehan [:dmeehan]]

I'll clear my need-info for now, since there was some information provided yesterday

Comment 23

[Stephen A Pohl [:spohl]]

Second attempt at a fix: The first one turned out to address only part of this, and the logs you sent showed why, so this build changes what happens on the page side as well.

Please repeat the same steps from comment 19 with this build:
https://firefoxci.taskcluster-artifacts.net/UeMT9HnyQQWCV14Aujt_rw/0/public/build/target.tar.gz

Please say how many of each landed in the chat box. If the anchored picker still drops them, the log should tell us which of two remaining paths we are on, so the run is worth doing either way.

The content sandbox is off for that run, so please quit the build afterwards.

Comment 24

[Eric Taylor]

Attachment: emoji logs target3--et.zip

OK it worked! I did like 7 clicks docked because I wanted to really test it. And another 4 to 5 undocked. Think you got it! Also launched once without logging and did another run of about 10+ and it worked repeatedly it seems.

Thanks!

Comment 25

[Stephen A Pohl [:spohl]]

Eric, could I ask you to test one more build for me? It carries a smaller change, with the larger one switched off, to find out whether the smaller change is enough on its own.

https://firefoxci.taskcluster-artifacts.net/RlE0yN6JTI2aX3WAOJuFKA/0/public/build/target.tar.gz

Same steps as before:

1. Unpack it and de-quarantine the extracted app.
2. Launch it from Terminal:

MOZ_DISABLE_CONTENT_SANDBOX=1 ~/Downloads/"Firefox Nightly.app"/Contents/MacOS/firefox

3. On Twitch, insert a few emoji with the picker anchored to the chat box, then a few more with it dragged out to the floating palette.
4. Quit Firefox and attach everything this lists:

ls /tmp/emoji-*

If you could let me know how many of each landed in the chat box, that would be great. Thank you!

Comment 26

[Eric Taylor]

Attachment: emoji logs target4--et.zip

This still seems to have done the trick still! I did 4 of each, docked and then undocked.

Comment 27

[Stephen A Pohl [:spohl]]

Attachment: Bug 2060994: Log the text that the macOS Emoji picker inserts, rather than "(null)". r?#mac-reviewers!

GetCharacters() escapes each UTF-16 code unit on its own, so a character outside the Basic Multilingual Plane ended up in the escaped string as two unpaired surrogates with the escape text between them. XPCOMStringToNSString() cannot convert that, returns nil, and every such character was logged as "(null)". Most Emoji are outside that plane, so the logs collected for this bug hid the very text we were following.

Keep a surrogate pair together and log the code point it forms, and leave a lone surrogate out of a string that it cannot be converted in. While here, log which of the two ways of inserting text without a key press is in use, since the two behave differently and the choice is not otherwise visible in a log.

Comment 28

[Stephen A Pohl [:spohl]]

Attachment: Bug 2060994: Ignore a resign-key notification for a window which is still the key window on macOS. r?#mac-reviewers!

Opening a panel such as the Emoji picker gets us NSWindowDidResignKeyNotification for a window which NSApp still reports as its key window at that moment, and which is still the key window a turn of the event loop later, while the panel stays up and keeps sending us the text the user picks. Logging on an affected machine shows the same window pointer as the notification's object and as NSApp.keyWindow, six times over six uses of the picker.

We treated each of those as the window being lowered. nsFocusManager then blurred the content, the content process lost its focused editor, and an emoji arriving in the meantime reached the editor with no editing host to dispatch a "beforeinput" event at, so the page was never told about it and the emoji did not appear. The same emoji inserted from the picker's floating palette, which does not get us this notification, worked.

Wait for the next turn of the event loop before deciding, and leave a window alone if it is the key window again by then. A window which really lost key to another window or to another application is not, and still deactivates. Sheets are unchanged.

Verified on macOS by the reporter of this bug: eight emoji from the anchored picker, all inserted, and the log shows the content never lost focus.

Comment 29

[Stephen A Pohl [:spohl]]

One more build, sorry. The fix in comment 25 works, but I have simplified the patch and want to make sure that this is still working as expected:

https://firefoxci.taskcluster-artifacts.net/DQ5hzGYpRZyJZISqNmkOJw/0/public/build/target.tar.gz

Nothing to set up this time, and there is no logging in this build:

1. Unpack it and de-quarantine the extracted app:

xattr -dr com.apple.quarantine ~/Downloads/"Firefox Nightly.app"

2. Launch it normally, from Finder is fine.
3. On Twitch, insert a few emoji with the picker anchored to the chat box, and a few with it dragged out to the floating palette.

If you could let me know how many of each landed in the chat box, that is all I need. Thanks again!

Comment 30

[Eric Taylor]

Hi there, I was able to launch and emoji still inserted as expected, both docked and undocked. (Did 3 docked, 4 undocked.)

I don't see any logs to pack up and send to you though?

Actually I launched a second time and did 5 docked via keyboard entry and then 5 undocked, too. Everything worked as expected.

Comment 31

[Stephen A Pohl [:spohl]]

Sorry, I did some copy and pasting and it might have gotten buried, but in comment 29, I mentioned:

(In reply to Stephen A Pohl from comment #29)

[...]
Nothing to set up this time, and there is no logging in this build:
[...]

So your test results were exactly what I was hoping for and there were no logs to collect. Thanks again for being so responsive!

Comment 32

[Eric Taylor]

No problem, glad to help! It will be so nice to have emojis working right!

Comment 33

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0cf9365b42a5
https://hg.mozilla.org/integration/autoland/rev/a6c3082b0681
Log the text that the macOS Emoji picker inserts, rather than "(null)". r=mac-reviewers,mstange
https://github.com/mozilla-firefox/firefox/commit/599182662b8c
https://hg.mozilla.org/integration/autoland/rev/f413cef2c2b2
Ignore a resign-key notification for a window which is still the key window on macOS. r=mac-reviewers,bradwerth

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/73a21488aa7f
https://hg.mozilla.org/integration/autoland/rev/8410d9ebc561
Revert "Bug 2060994: Ignore a resign-key notification for a window which is still the key window on macOS. r=mac-reviewers,bradwerth" for causing wpt failures.

Comment 35

[Serban Stanca [:SerbanS]]

Reverted this because it was causing wpt failures.

• Revert link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | /fullscreen/api/document-fullscreen-keyboard-lock-multiple-elements.window.html | Requesting fullscreen with keyboard lock, then on another element without keyboard lock, then exitFullscreen() - assert_equals: fullscreen should activate expected Element node <body><div id="log"></div>

Please, also check this one.

Comment 36

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/a6c3082b0681
https://hg.mozilla.org/mozilla-central/rev/f413cef2c2b2

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/64cfaf34e56f
https://hg.mozilla.org/mozilla-central/rev/d250b3077d8d
Revert "Bug 2060994: Ignore a resign-key notification for a window which is still the key window on macOS. r=mac-reviewers,bradwerth" for causing wpt failures.

Comment 38

[Stephen A Pohl [:spohl]]

sstanca, I looked into the wpt failures this was backed out for, and I don't believe this patch caused them.

1. The same failures show up without it. The shippable wpt8 job on a mozilla-central push that doesn't contain this patch failed document-fullscreen-keyboard-lock-escape.window.html (https://treeherder.mozilla.org/logviewer?job_id=599365629&repo=mozilla-central), and after the backout wpt8 on autoland failed twice more in the same family of tests, as you noted in bug 2081232 comment 1.
2. Over the last day, macOS 15 opt wpt8 on autoland has failed in roughly half of its runs, with or without this patch.
3. The Android failure from comment 35 is a prerender timeout in a GeckoView job, which a macOS-only widget change shouldn't be able to affect.

So this looks like it was caught by the intermittent tracked in bug 2081232 rather than causing it. If you agree, could you reland D319917? D319916 stayed in and doesn't need anything.