Closed Bug 1478347 Opened 6 years ago Closed 7 months ago

macOS native "Emoji's & Symbols"-picker not in Edit menu when switching language

Categories

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

Product:
Core
Component:
Widget: Cocoa
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
122 Branch
Tracking Flags:
Tracking Status
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox79 --- wontfix
firefox80 --- wontfix
firefox84 --- wontfix
firefox85 --- wontfix
firefox96 --- wontfix
firefox97 --- wontfix
firefox98 --- wontfix
firefox122 --- fixed

People

(Reporter: info, Assigned: spohl)

References

Details

Attachments

(4 files)

emojis-and-symbols-menu-bar-mac.jpg
59.78 KB, image/jpeg
Details
Firefox 81b2 Edit menu in Spanish.
119.39 KB, image/png
Details
Chrome 85.0.4183.83 64bits Edit menu in Spanish
175.72 KB, image/png
Details
Bug 1478347: Ensure that macOS-provided menu items are available in the Edit menu, especially in multi-language environments where Firefox may have a different language than the OS. r=mstange
48 bytes, text/x-phabricator-request
Details | Review 
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180723144101

Steps to reproduce:

1. Go to Edit menu
2. Try to find 'Emoji's & Symbols' (present in almost any macOS app, including Chrome)


Actual results:

Not there


Expected results:

Expected to be present (may be next to 'Start dictation'); both are additional services offered by macOS as native controls that may input text into a focussed field (either an emoji or symbol, or text that is recorded and processed via macOS' own dictation system)
Note that https://bugzilla.mozilla.org/show_bug.cgi?id=1232371 is slightly related, but it discusses a cross-platform emoji picker. This is merely making the native control accessible.
I verified this issue on Mac 10.12 with Firefox Beta 62.0b12 (2018-07-26) (64-bit) and latest Firefox Nightly 63.0a1 (2018-07-30) (64-bit). The "Emoji & Symbols" option is displayed. Please note that I cannot reproduce this issue after following your steps.
Could you please test this in safe mode? Here is a link that can help you: https://goo.gl/AR5o9d.
I think it will be a good idea to retest this on Firefox Nightly. Here is a link form where you can install Firefox Nightly: https://nightly.mozilla.org. 
If you still have the issue please create a new profile, you have the steps here: https://goo.gl/Awo6h8.
Flags: needinfo?(info)
Thanks for your reply. I did some additional searching, and I just learned that it is not present in the *Dutch* versions of Firefox, sorry, was unaware of it being a locale-related issue (not in nightly, not in safe mode, not in beta)

Tried to search for Firefox on the Dutch Pontoon page, but was unable to find the Firefox project. But maybe a translation string is missing?

  en (Firefox Nightly)           nl (OSX Mail)
Start dictation...          => Start dicteren       fn fn
Emoji & Symbols    ^⌘Space  => Emoji en symbolen  ^⌘Space
Flags: needinfo?(info)
Summary: macOS native "Emoji's & Symbols"-picker not available in macOS Edit menu → [nl] macOS native "Emoji's & Symbols"-picker not available in Dutch/Nederlandse macOS Edit menu
I verified this issue on nl build and the "Emoji's & Symbols" is not displayed. I also verified the same issue on ar build and the result is the same, "Emoji's & Symbols" is not displayed. I'm not sure if this behaviour is intended or we have a bug here. I will set this the right component and I will mark as enhancement until we know what is the proper behaviour.
Status: UNCONFIRMED → NEW
status-firefox61: --- → affected
status-firefox62: --- → affected
status-firefox63: --- → affected
Component: Untriaged → Widget: Cocoa
Ever confirmed: true
Product: Firefox → Core
Moving this to Localization. It would be great if someone could verify if there are any strings that we're translating for this feature, and if there might be a discrepancy between what the OS expects and what we provide.
Component: Widget: Cocoa → Localization
I see it in the Italian Nightly: 66.0a1 (2019-01-02) (64 bit) macOS 10.13.6

There is not a single string in the entire codebase using the work "emoji", but it's translated as "Emoji e simboli" in Italian, so I guess that comes from the OS (together with the "Start dictation…" menu). I'm not completely sure this is a localization issue, more an OS integration one?

Likely some kind of interaction issue between Firefox and the OS, perhaps in how it presents its locale/language. I notice that if I have my browser language set to US English, the menu entry appears and Cmd-Ctrl-Space works to open the emoji picker. But, if I set Firefox to use Esperanto, neither the menu entry nor the keyboard shortcut function. This happens independently of what my system language is set to.

Given that we don't localize anything related, bumping back to platform integration aka Widget: Cocoa.

I forgot how we hook up the main menu into macos general menu items that are independent of the window we localized.

Component: Localization → Widget: Cocoa
Priority: -- → P3

Reading a thread at stackoverflow (1) made me take a closer look at the nl translations of the Edit menu label:

The label of the nl edit menu is translated to "Bewerken" (2) in Firefox, but it looks like it's translated to "Wijzig" in MacOS (checked by switching primary language to Dutch and launching Safari).

The OS adds those menuitems automagically to any apps Edit menu, so I believe renaming the menu label to "Wijzig" would make both menuitems appear in the nl version of Firefox.

(1) https://stackoverflow.com/questions/18870965/remove-dictation-and-special-characters-menu-options-from-nsmenu
(2) https://dxr.mozilla.org/l10n-central/rev/c4aff44c3bc8cc2bcb92cd68b1fa224d905f00fc/nl/browser/chrome/browser/browser.dtd#415

Thank you for looking into this, Stefan! Bumping back to localization for now per comment 9.

Component: Widget: Cocoa → Localization

Moving over to Dutch.

Looking at https://www.microsoft.com/en-us/language/Search?&searchTerm=Edit&langID=155&Source=true&productid=0, "Bewerken" is the standard windows translation.

If that's so, we'll need to wait for Fluent in the app menu bar, and then Dutch could add a platform selector to align with macos just on macos :-)

Assignee: nobody → dutch.nl
Component: Localization → nl / Dutch
Product: Core → Mozilla Localizations
Version: 62 Branch → unspecified

"Bewerken" is indeed the standard Windows translation. Unfortunately Dutch Apple uses a lot of imperatives like "Wijzig", which isn't the term we like to use in Dutch translations. I hope this issue can be fixed with Fluent…

Not sure how or why, but simply switching the Firefox locale from Dutch to English (United States) does not enable the "Dictation" and "Emoji & Symbols" menu items.
That would have been a temporary workaround for people that don't care so much which of those two languages is used.

I think this is also a problem with the French locale. Specifically, I think I was on Suisse (Fr) when my computer was given to me. I changed the language of the system and of Firefox to English (UK), but I still cannot see the menu in Edit, and the shortcut Ctrl + Cmd + Space is not working (as opposed to any other app on my computer).

So indeed, it is not coming back. This is Firefox 73.0.1 on MacOS Catalina 10.15.2.

I'll try to reinstall firefox soon and see if I can get it back

I'm experiencing the same issue for the Spanish language on Firefox Developer 75.0b11 and Mac OS Catalina 10.15.4 (19E266). It's quite annoying since I have to use this functionality several times per day.

@ciprian.tomoiaga and @oliver.cg89 , can you verify the proposed problem from comment 11? I.e., is the translation for "Edit" in the French and Spanish localizations distinct from the "Edit" translation used in other MacOS applications? Are the translations more in-line with the Windows translations?

(In reply to Jeff Beatty [:gueroJeff] from comment #19)

@ciprian.tomoiaga and @oliver.cg89 , can you verify the proposed problem from comment 11? I.e., is the translation for "Edit" in the French and Spanish localizations distinct from the "Edit" translation used in other MacOS applications? Are the translations more in-line with the Windows translations?

Unfortunately, the translation for the "Edit" menu is the same than other apps. I've just checked it with Chrome (where the emoji shortcut and keyboard is present) and Firefox, and the translation is the same "Editar".

If that's the case, then this issue likely wouldn't be solved by Fluent or a different translation. It also means it's more pervasive than just Dutch. Moving back to Core.

Assignee: dutch.nl → nobody
Component: nl / Dutch → Localization
Product: Mozilla Localizations → Core

[Tracking Requested - why for this release]:

status-firefox75: --- → affected

I'm moving this to Cocoa, as we're not doing anything to anything in the Localization component right now.

I think there are two paths forward:

  • WONTFIX. If the UI translation can differ from things that macos detects as "Edit", say by an unsupported localization on the macos side, then it's not going to add the menus, and that's that.
  • Hack around the Edit menu, and unhack in awakeFromNib

The latter is just guessing from the stackoverflow thread, which mentioned "hack Edit, and then change it back". In our case, we'd hack "Edit" to be actually detected, and then change the translation to be something that we want, but may not be detected.

I'm leaving this up to the macos integration folks to decide.

Component: Localization → Widget: Cocoa
status-firefox79: --- → affected

If this can help : This happens when I use the en_US locale in Firefox while my macOS 10.14.6 is fr_FR. If I switch firefox back to fr_FR the menu appears.

I experience this using Spanish locale on macOS with the Spanish version of Firefox. The menu item says "Edición" in other Mac apps, but in Firefox it says "Editar". I just manually changed the locale string in Firefox to "Edición" and the emoji picker now shows up so it's literally just the value of the string which is causing the issue. If there's some way you can make Firefox always use the macOS default "Edit" menu item string for whatever locale you're in, then that should fix the problem for everyone.

You can see that the string Edit menu in Spanish is "Editar" but there is no sign of the emoji keyboard.

(In reply to dannyjkirkham from comment #25)

I experience this using Spanish locale on macOS with the Spanish version of Firefox. The menu item says "Edición" in other Mac apps, but in Firefox it says "Editar". I just manually changed the locale string in Firefox to "Edición" and the emoji picker now shows up so it's literally just the value of the string which is causing the issue. If there's some way you can make Firefox always use the macOS default "Edit" menu item string for whatever locale you're in, then that should fix the problem for everyone.

This is my scenario. Both, Mac OS 10.15.6 and Firefox 81b2 are set to Spanish but it's even more strange. In my case, both Google Chrome (for example) and Firefox has the same string for the Edit menu: "Editar". However, in the case of Chrome there you can see the emoji keyboard.

Same issue here
Firefox 80.0.1 (64-bit) on macOS Catalina, both system and firefox application are set to English (US)

I'm also affected. Firefox 82.0.2 (64-bit) on macOS Catalina 10.15.6.

My default UI language is English, but I also have Finnish as a selectable language. If I use English, I don't have the "Edit -> Emojis & symbols" menu, but if I use Finnish, I do.

(In reply to jarno from comment #30)

I'm also affected. Firefox 82.0.2 (64-bit) on macOS Catalina 10.15.6.

My default UI language is English, but I also have Finnish as a selectable language. If I use English, I don't have the "Edit -> Emojis & symbols" menu, but if I use Finnish, I do.

Screenshot in Finnish: https://user-images.githubusercontent.com/560055/97622717-52cdc680-1a2d-11eb-9e37-7eab8d19a2c0.png

Screenshot in English: https://user-images.githubusercontent.com/560055/97622737-59f4d480-1a2d-11eb-8fc5-4a2b4027303b.png

My default UI language is English, but I also have Finnish as a selectable language. If I use English, I don't have the "Edit -> Emojis & symbols" menu, but if I use Finnish, I do.

I can confirm that with English and German UI Language.

  • English: Menu item does not exist
  • German: Menu item does exist

The problem persists on MacOS Big Sur 11.0.1 (20B29).

Can confirm this problem on Mac OS 10.12 Firefox Stable 83.0. "Emoji & Symbols" appears when Russian is chosen as the default language. However, when English (US) is the default language, the option is not available in "Edit" menu.

![image of Russian Edit menu] (https://snipboard.io/JD0pv3.jpg)

Confirmed problem here as well, macOS 10.15.7, Firefox 83. Note that it seems connected to OS Region, not OS language. My mac is set to

Region: Norway

Preferred languages:
English
English — Primary

Norsk bokmål
Norwegian Bokmål

Firefox was set to English UK. I tried changing to English US just in case, but no effect. Changing Firefox language to Norwegian however (specifically "Norsk (bokmål) (Norge)") resulted in the emoji option showing up in the edit menu (or rather the "Rediger" menu).

I'm having the same problem. I think it's also connected to the localization country rather than the language.

My OS is setup for "English (Sweden)" and firefox for "English (USA)", if I switch Firefox to "Swedish (Sweden)" then the emoji menu appears, if I switch back to "English (USA)" then it dissapears.

Currently using Mac OS Big Sur 11.0.1 (20B50) with Firefox 84.

I can confirm this problem is also found on Mac OS Big Sur 11.1 (20C69).

Summary: [nl] macOS native "Emoji's & Symbols"-picker not available in Dutch/Nederlandse macOS Edit menu → macOS native "Emoji's & Symbols"-picker not in Edit menu when switching language

(In reply to oliver.cg89 from comment #28)

(In reply to dannyjkirkham from comment #25)

I experience this using Spanish locale on macOS with the Spanish version of Firefox. The menu item says "Edición" in other Mac apps, but in Firefox it says "Editar". I just manually changed the locale string in Firefox to "Edición" and the emoji picker now shows up so it's literally just the value of the string which is causing the issue. If there's some way you can make Firefox always use the macOS default "Edit" menu item string for whatever locale you're in, then that should fix the problem for everyone.

This is my scenario. Both, Mac OS 10.15.6 and Firefox 81b2 are set to Spanish but it's even more strange. In my case, both Google Chrome (for example) and Firefox has the same string for the Edit menu: "Editar". However, in the case of Chrome there you can see the emoji keyboard.

This is precisely the issue I have. Every locality of the Spanish language pack I try uses Editar and Ver instead of Edición and Visualización. I tried to edit the names inside of the .xpi but it invalidated the extension.

Region: South Korea
Language: English (English) - Primary, Korean

I'm running Firefox 95.0.2 (64-bit) on macOS 12.1 (Mac Mini M1).
Emoji & Symbols menu is still missing from 'Edit' menu, along with 'Start Dictation' as well.
This is still a thing after four years.

This is becoming a bigger problem. For me with Firefox and macOS both set to english I am no longer able to invoke emoji picker in Firefox at all. This bug here is about the missing menu entry and is four years old. But if I am not mistaken, invoking emoji picker in Firefox via ⌃⌘space worked fine during the past 4 years. Should I file a separate bug about that or is the problem of not being able to invoke emoji picker at all the same problem as this bug here? If it is, I would love to see priority raised. Emoji use has become quite common and this feature being broken for all macOS users is a problem I think. It becomes more severe as there are platforms relying on system emoji pickers to work since they don't have a great emoji picker solution themselves (e.g. friendica).

macOS: 11.6.2
Firefox: 95.0.2

@steve, it doesn't appear to be separate. At least for me the two issues seem to go hand-in-hand.

And same here, feels petty but I'm considering switching to another browser, it's that annoying.

Still happens with Firefox 96 and 97 beta in macOS 12.1

I'm using the Swedish locale and affected as well (Firefox 96.0.3). The regular ctrl+cmd+shift combination does not work for me either, however I just figured out that I can invoke the emoji picker in Firefox by just pressing the fn key. So now I can use emojis in Firefox again 👌

Whatever got changed, on macOS 12.2.1 (21D62) and Firefox 97.0.1 (64-bit) ctrl cmd space again invokes the emoji picker as expected 🙌

Closing based on comment 45. Please let us know if you're still experiencing this issue on macOS 12.2.1 (21D62) or later.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME

Hi,

I can confirm that the problem persists on Mac OS 12.2.1 (21D62) and Firefox 98.0b8, Spanish language.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

(In reply to Stephen A Pohl [:spohl] from comment #47)

Closing based on comment 45. Please let us know if you're still experiencing this issue on macOS 12.2.1 (21D62) or later.

I'm afraid that's premature. This problem seems to happen very inconsistently (I randomly see it too, for example right now I don't have that menu on Nightly and macOS 12.2.1).

It is still present and was never resolved. macOS 12.2.1 (21D62) and Firefox 97.0.1
The issue is we don't get "Start Dictation" and "Emoji & Symbols" menu under "Edit", not that we couldn't bring up emoji picker by shortcut.
Bringing up emoji picker by shortcut has always worked if you set the emoji picker to open when globe key is pressed.

Obviously persisting for many. @me what you write is not correct as per https://bugzilla.mozilla.org/show_bug.cgi?id=1478347#c41 and what is described there is no longer persisting. Since the issue seemed related (as was discussed on mozilla matrix channel back when) I added my findings as I did with the changed behavior I am seeing now.

@Stephen: sorry for the premature enthusiasm. However invoking emoji picker was indeed broken and is now working. As mentioned not sure, maybe some local app was blocking the keyboard shortcut, at least I did not (knowingly) change anything about shortcuts.

Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(spohl.mozilla.bugs)

I use macOS with English locale. I had downloaded Firefox in Brazilian Portuguese, and then switched it to use Brazilian Portuguese instead, and Emoji & Symbols was not available in the Edit menu. After reading these comments, I uninstalled Firefox and reinstalled using the English installer, and the Emoji & Symbols item is working as expected.

Firefox 102.0.1 on macOS 11.5.1 (Big Sur)

Severity: normal → S3

Just a heads up, if you download the wrong language version, it doesn't work just "replacing it" from Applications. You have to delete the old one and copy the new one. At least that was my experience.

(In reply to jfromaniello from comment #54)

Just a heads up, if you download the wrong language version, it doesn't work just "replacing it" from Applications. You have to delete the old one and copy the new one. At least that was my experience.

This. So much time’s passed and I’ve seen this suggestion a few times, which I’ve personally tried and worked in my case: deleted the old app, downloaded and installed the localized version and the Emoji picker in the menu as well as the keyboard shortcut worked out of the box.

Even after installed additional dictionaries, or even changing Firefox’s UI language, when reverting to the “original” one, the menu item and shortcut persisted. Maybe this isn‘t quite a bug but a design feature? 😅 (<- typed using the keyboard shorcut).

(In reply to jfromaniello from comment #54)

Just a heads up, if you download the wrong language version, it doesn't work just "replacing it" from Applications. You have to delete the old one and copy the new one. At least that was my experience.

This worked for me as well! Although uninstalling and reinstall via Homebrew didn’t work. I had to manually drag the application into the trash and download it from https://www.mozilla.org/firefox/

I can confirm, that the emoji keyboards doesn't show up, when Firefox uses another locale as the system does.

Firefox 111.0, macOS 12.6.3

Another confirmation here.
Firefox 111.0 64 bit
macOS 13.2.1

Additional info:

  • macOS language is set to Spanish

  • Starting Firefox with "US" as language brings up the emoji menu. Changing language to "Spanish" without closing Firefox keeps the menu available, however, if I open up Firefox in "Spanish" the emoji menu is missing (same for other languages like "Català"). The opposite (starting Firefox in "Spanish" and changing back do "US") doesn't bring up the emoji menu.

Other non-apple applications with localized menus that have the emoji menu: "Chrome", "Joplin"
Other non-apple applications with localized menus that doesn't have the emoji menu: "Thunderbird",

I have made some tests like downloading English version of Firefox and adding language pack later or downloading Spanish build directly but behavior doesn't change.

IMHO it's clear that macOS does some manipulation of the application's menu at app's startup based on some heuristics.

I encountered this issue with English system (Ventura) language and German Firefox UI. Changing Firefox' language to English solved it after restarting the app.

I just wanted to add an important UX aspect:
When the "Emoji & Symbols" menu item is missing, this also breaks the ctrl+cmd+space keyboard shortcut to bring up the emoji picker.
This is not an issue when using the built-in Mac-Keyboard which has a Globe/Emoji key. But when you use an external keyboard, it is a real problem.

For some good research on this issue, please see https://bugreports.qt.io/browse/QTBUG-79565, particularly the last comment and the self-contained example program "editmenu.mm".

In short, there are two ways to get the menu detected:

  1. Set the title of the NSMenuItem containing the Edit menu to the string macOS expects. It can be set to whatever without affecting the user-visible title of the menu, which is a property of the actual NSMenu.
  2. Make sure there's at least one menu item with a known edit action.

I don't know which route is easier to implement, but nsMenuUtilsX::GetStandardEditMenuItem() already satisfies the second condition. However, this function is only responsible for building the Edit menu for modal dialogs.

Perhaps someone suffering from this bug whose system language is not English [1] could see if the Edit menu contains the "Emoji & Symbols" item when the "Open File" dialog (Cmd-O) is open. If it does, then that would suggest that what nsMenuUtilsX::GetStandardEditMenuItem() is doing with the action properties should be enough to fix the issue when applied to the main application menu as well.

[1] Because in GetStandardEditMenuItem the menu title is hardcoded in English.

Assignee: nobody → spohl.mozilla.bugs

(In reply to bintoro from comment #60)

For some good research on this issue, please see https://bugreports.qt.io/browse/QTBUG-79565, particularly the last comment and the self-contained example program "editmenu.mm".

Thanks for pointing to this. Since we want these menu items to be available regardless of the language combination used (for example, "de-CH" Firefox on "en-US" macOS) we want to go the route of the menu item that macOS recognizes as having an "edit action" in the Edit menu. While working on my patch I found that there are many more restrictions on what macOS will recognize as an "edit action" than what was mentioned in the bug report that you linked to: First, this only appears to work for the copy: action. No other edit actions seem to get recognized. Secondly, the NSMenuItem's target must remain the default target. If set to a custom target, macOS will stop adding the extra menu items to the Edit menu.

I have confirmed that my patch works for Firefox with "fr" locale on macOS running "en-US".

Pushed by spohl@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/df3ec72035f3
Ensure that macOS-provided menu items are available in the Edit menu, especially in multi-language environments where Firefox may have a different language than the OS. r=mstange

https://hg.mozilla.org/mozilla-central/rev/df3ec72035f3

Status: REOPENED → RESOLVED
Closed: 2 years ago → 7 months ago
status-firefox122: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 122 Branch

Thank you @spohl! Can confirm it was fixed in the nightly for the scenario where the OS locale is nl-NL, but the FF UI is en-US.

The original bug was about running FF UI in nl-NL as well, but the nl-NL language pack is not yet ready for 122, so can't confirm that yet, but I guess it is the same issue.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: