1833923 - macOS emoji popup shortcut enters "e" symbol

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect, P3)

Description

[wojtek]

Attachment: firefox-macos-emoji-popup-edit-menu.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/113.0

Steps to reproduce:

Place cursor in input field
Hit fn+e shortcut

Actual results:

letter "e" is inserted nad emoji pop-up is shown

Expected results:

Only the popup should be shown

Comment 1

[wojtek]

Attachment: firefox-macos-emoji-popup-e-letter-input-field.png

Comment 2

[wojtek]

Bizzarly enough, ctrl+cmd+space works.

My macOS system locale is spanish but I have firefox in english.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

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 5

[Jeremiah Lee]

I can duplicate this bug in macOS Sonoma 14.0 and Firefox 118.0.1.

Related to bug 1855346 that uses the prior macOS global shortcut (control+command+space) for the Emoji & Symbols Character Viewer.

Comment 7

[Carlos Duarte do Nascimento (Chester)]

Did a proof-of-concept on fixing this bug and 1855346 ; details here; will try to evolve it into a reviewable path; any guidance welcome!

Comment 8

[Carlos Duarte do Nascimento (Chester)]

As I mature the a fix for 1855346, I noticed this error on the Nightly logs when fn-e is pressed¹:

firefox[32185:1201239] [Error] invalid range passed to IMK -attributedSubstringFromRange : inputSource = com.apple.CharacterPaletteIM

Will dig later but may suggest something to someone.

¹ regardless of whether the Emoji & Symbols shortcut has been redefined or not, that is, regardless of whether fn-e will actually activate Emoji & Symbols - since it only activates if you don't redefine the shortcut

Comment 9

[Carlos Duarte do Nascimento (Chester)]

(to be fair, that happens whenever a shortcut is pressed and the box is non-empty; so it might be something else, apologies for the noise)

Comment 10

[bintoro]

Isn't this as simple as just not outputting any characters when the event contains Fn or Fn+Shift as the only modifier(s)?

Fn is reserved for system shortcuts. But even if I set up Fn+something as a hotkey for a special character, the modifier flag won't be present in the final event received by the application. So, I can't think of any reason not to implement a general solution here.

Preventing output consistently and not special-casing Fn+E would also be future-proof. There are several undocumented Fn shortcuts and probably more to come. These shortcuts seem to be susceptible to weird behavior in cross-platform apps. For instance, in VS Code, Fn+M prints "m" in addition to doing the system action (moving focus to the menu bar).

Comment 11

[Carlos Duarte do Nascimento (Chester)]

Yes, ideally we should be as generic as possible. The reason I targetted the current fix for bug 1855346 towards the specific Emoji & Symbols action (and did not concern on fixing this bug anymore) was because fn- shortcuts like this one don't even reach that point in the code (and not doing any targetting would break other system shortcuts, such as "Hide Firefox" / "Hide Other Windows").

But for this one, yeah, I'd go generic - even more so if we have a confirmation that Fn-* shortcuts are reserved for system use, I'd pursue a generic fix. Do we have any documentation supporting that? (I can confirm empirically that we can't add an App Shortcut using Fn-*; the only attributtable Fn thing is the action for hitting the key alone, which is not a concern for this bug; but some official docs would be reassuring).

Comment 12

[bintoro]

Some discussion here:
https://mjtsai.com/blog/2023/05/02/fn-key-reserved-for-system-applications/

AFAIK, outside of the Apple world, the Fn key is not even transmitted to the OS as a keycode but is mostly handled by keyboard firmware. On Apple hardware, Fn status is available to software, but it isn't a regular modifier. For instance, Fn-Left is not just a key combo with a binding to a "Home" action; it is the Home key.

More to the point, I can't imagine a situation where printing a character upon an event that has Fn as a modifier is in any way meaningful. Right now, if I press Fn+M when Firefox is active, the menu bar gets focus and Firefox doesn't even see the keydown event. But if I press Fn+Y, "y" is printed. It's pointless, particularly since Apple may assign Fn+Y to a system-wide action at any time.

I don't really understand why Fn behaves in this way in the first place. If an app doesn't have use for, say, the Cmd-A combo, it doesn't mean Cmd-A is going to print "a". It just doesn't do anything. IMO it's only logical that the same should apply to Fn, and I fully expect that to be where things are heading.

Comment 13

[Carlos Duarte do Nascimento (Chester)]

Just for cross-reference: the fix for bug 1855346 (currently under review) also fixes this bug (on Sonoma, at least).

Comment 15

[Stephen A Pohl [:spohl]]

I was just getting ready to return to this when I realized that I can't seem to reproduce this anymore. I have recently upgraded macOS to 14.4 (23E214). I'm not sure if this has something to do with it.

To anyone following this bug, could you comment if you're able to still reproduce this issue? And if so, on what version of macOS and Firefox?

If this no longer reproduces on more recent versions of macOS, I'm tempted to land bug 1855346 now.

Comment 16

[Carlos Duarte do Nascimento (Chester)]

Unfortunately, the problem still happens for me on:

• Firefox 123.0.1
• macOS 14.4 (23E214);
• Apple M1 Pro

Worth noticing that, as opposed to bug 1855346 (which happens pretty much consistently), this one is intermittent: when pressing fn/globe + e, sometimes the picker stays open, and sometimes an "e" isn't printed; maybe you had a lucky strike?

Comment 17

[Stephen A Pohl [:spohl]]

Yes, I'm now able to reproduce again. I'm not sure what could have triggered this. Thanks for confirming!

Comment 18

[wojtek]

@spohl

I was just getting ready to return to this when I realized that I can't seem to reproduce this anymore. I have recently upgraded macOS to 14.4 (23E214). I'm not sure if this has something to do with it.

To anyone following this bug, could you comment if you're able to still reproduce this issue? And if so, on what version of macOS and Firefox?

I'm on 14.5, and it's still happening almost constantly.

(for some reason I was "unfollowed" from this issue even though I reported it o_O)

Comment 19

[Stephen A Pohl [:spohl]]

Attachment: Bug 1833923: Start detecting when the Fn key is pressed on macOS, which allows for built-in macOS shortcuts (such as Fn+e for the emoji picker) to start working. r=masayuki!

Comment 20

[quadronom]

Does anybody has tested it on Sequoia?
On Sonoma it is still happening.

Comment 21

[Stephen A Pohl [:spohl]]

(In reply to quadronom from comment #20)

Does anybody has tested it on Sequoia?
On Sonoma it is still happening.

There is no difference in behavior on Sequoia and the bug occurs there too.

Comment 22

[wojtek]

(In reply to quadronom from comment #20)

Does anybody has tested it on Sequoia?
On Sonoma it is still happening.

I'm still on Sonoma (very weary to upgrade until next patch release these days…)

Btw.
(In reply to wojtek from comment #2)

Bizzarly enough, ctrl+cmd+space works.

this doesn't work but there is a separate issue about that: https://bugzilla.mozilla.org/show_bug.cgi?id=1855346 #1855346 which is now locked 🤷‍♂️

Comment 24

[Stephen A Pohl [:spohl]]

Masayuki-san, could I bother you for another review of the patch in this bug? Thank you!

Comment 25

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

Sorry, I was on PTO.

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4a977ca5fd56
Start detecting when the Fn key is pressed on macOS, which allows for built-in macOS shortcuts (such as Fn+e for the emoji picker) to start working. r=masayuki

Comment 27

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/4a977ca5fd56

Comment 28

[Stephen A Pohl [:spohl]]

Release Note Request (optional, but appreciated)
[Why is this notable]:

This was a usability issue affecting our macOS users.

[Suggested wording]:

Starting with macOS Sonoma, the emoji picker that could be opened using the Fn+e shortcut would also insert the character e in the currently selected text field/box when opening the emoji picker. We have been able to fix this universally for this and similar shortcuts using the Fn key going forward.

Comment 29

[Donal Meehan [:dmeehan]]

Added to the Fx133 nightly release notes, please allow 30 minutes for the site to update.
Keeping the relnote-firefox flag as ? to keep it on the radar for inclusion in the final Fx133 release notes.

Comment 30

[Norisz Fay [:noriszfay]]

Backed out as requested for causing multiple regressions

Backout link

Comment 31

[Donal Meehan [:dmeehan]]

Removed the relnote from Fx133 nightly.
Nucleus Note for future reference when this lands again and relman want to add it back.

Comment 33

[Norisz Fay [:noriszfay]]

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/6e36bd20ffeb

Comment 34

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to Norisz Fay [:noriszfay] from comment #30)

Backed out as requested for causing multiple regressions

Backout link

No regression field in this bug, were any bugs filed in bugzilla? Those are in bug 1855346.

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eabc08680c7b
Start detecting when the Fn key is pressed on macOS, which allows for built-in macOS shortcuts (such as Fn+e for the emoji picker) to start working. r=masayuki

Comment 36

[agoloman]

Backed out for causing build bustages at nsMenuBarX.

• Backout link
• Push with failures
• Failure Log

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7ff29b4cda64
Start detecting when the Fn key is pressed on macOS, which allows for built-in macOS shortcuts (such as Fn+e for the emoji picker) to start working. r=masayuki

Comment 38

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/7ff29b4cda64

Comment 39

[Stephen A Pohl [:spohl]]

Attachment: Bug 1833923: Start detecting when the Fn key is pressed on macOS, which allows for built-in macOS shortcuts (such as Fn+e for the emoji picker) to start working. Patch for ESR128. r=masayuki!

Comment 40

[Stephen A Pohl [:spohl]]

Comment on attachment 9460815 [details]
Bug 1833923: Start detecting when the Fn key is pressed on macOS, which allows for built-in macOS shortcuts (such as Fn+e for the emoji picker) to start working. Patch for ESR128. r=masayuki!

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: The shortcuts for the emoji picker have been working inconsistently or not at all since macOS 14. This patch and the patch in bug 1855346 would address this on the ESR branch.
• User impact if declined: The emoji picker would work inconsistently or not at all using shortcuts for users on newer versions of macOS. A user would need to open the emoji picker from the main menu, or use browser extensions to get a similar behavior.
• Fix Landed on Version: 134
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): While the patches are not small, they have been released since Firefox 134 without any reported regressions.

Comment 41

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9460815 [details]
Bug 1833923: Start detecting when the Fn key is pressed on macOS, which allows for built-in macOS shortcuts (such as Fn+e for the emoji picker) to start working. Patch for ESR128. r=masayuki!

Approved for 128.7esr.

Comment 42

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/3c584e80b0c2

Comment 43

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Reproduced the issue on Firefox 115.0a1 (2023-05-18) on macOS 15.3 by following the STR from Comment 0.

The issue is fixed on Firefox 128.7.0ESR, Firefox 134.0.2 and Firefox 135.0 on the same system.