Closed Bug 1980815 Opened 11 months ago Closed 8 months ago

macOS emoji picker/symbol picker is broken after Firefox has been in the background once

Categories

(Core :: Widget: Cocoa, defect)

defect

Tracking

()

VERIFIED FIXED
145 Branch
Tracking Status
relnote-firefox --- 144+
firefox-esr128 --- unaffected
firefox-esr140 145+ verified
firefox141 --- unaffected
firefox142 --- wontfix
firefox143 --- wontfix
firefox144 --- verified
firefox145 --- verified

People

(Reporter: skyschub, Assigned: spohl)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

[Tracking Requested - why for this release]:

STR:

  1. Open a fresh Firefox
  2. Load data:text/html,<input>
  3. Focus the input, press CMD+CTRL+Space to open the emoji picker/symbol picker/whatever this thing is called
  4. Observe that the thingie works fine
  5. Switch the focus to another application - I used VSCode, but I think any application works.
  6. Focus back into Firefox, focus the <input>, press CMD+CTRL+Space again
  7. πŸ¦—, nothing happens

This is actually a regression from bug 1959023, and that fits with my "feelings". I noticed this being broken for a while, and even tried running mozregression before, but I felt like it's an intermittent issue. I just now realized that the way to break this is to focus on a non-Firefox window, that never crossed my mind before...

ni? :bradwerth as the regressor's author.

[Tracking Requested - why for this release]:

Primarily for visibility - while this bug is oddly infuriating for me at least, I don't quite have a suggestion here since the bug the regressor is fixing is also quite frustrating.

Flags: needinfo?(bwerth)

For some reason, if I have a "broken" state, opening a new Firefox window temporarily fixes the emoji picker. I can even switch back to the old window and the emoji picker works again in that window, too. Everything is fine until I switch focus to a different application, which breaks picking emojis in Firefox again.

Set release status flags based on info from the regressing bug 1959023

Thanks for filing. I'll try to improve behavior here.

Assignee: nobody → bwerth
Flags: needinfo?(bwerth)
Severity: -- → S3

The bug is marked as tracked for firefox142 (beta) and tracked for firefox143 (nightly). However, the bug still has low severity.

:jstutte, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Flags: needinfo?(jstutte)
Flags: needinfo?(jstutte) → needinfo?(spohl.mozilla.bugs)
Severity: S3 → S2
Flags: needinfo?(spohl.mozilla.bugs)

:bradwerth do you an update on this? Next week is RC week for 142

Flags: needinfo?(bwerth)

Not able to reproduce this on my setup. I'll keep trying.

When this happens to you, I'm guessing that the "Emoji & Symbols" menu item has disappeared from the "Edit" menu. Would you please verify? That might help me track this down from first principles.

Flags: needinfo?(bwerth) → needinfo?(dschubert)

Correct, if it's broken, the "Emoji & Symbols" menu item is indeed gone.

Flags: needinfo?(dschubert)

Set release status flags based on info from the regressing bug 1959023

:bradwerth just following up here in case we can still make it for a 142 dot release

Flags: needinfo?(bwerth)

(In reply to Dianna Smith [:diannaS] from comment #11)

:bradwerth just following up here in case we can still make it for a 142 dot release

Thanks. I still don't have a solution for this. I'm actively working on it.

Flags: needinfo?(bwerth)
Duplicate of this bug: 1954811

I'm struggling to make progress on this. I am using a much simpler Steps to Reproduce as follows:

  1. Launch Firefox.
  2. Check the Edit menu. Does it have "Emoji & Symbols" on the bottom? It should.

When I launch Nightly, the publicly-available build that everyone has access to, I don't see the Emoji menu item. This is in tree right now. I see the same buggy behavior on my locally-built version, and when I locally backout Bug 1959023, the problem remains. I don't think this is actually the regressor, though that Bug definitely touched a lot of relevant code.

Dennis, would you please try my STR above (just launch Firefox and check the Edit menu) and report what you see? I can't imagine there's a subtle difference in hardware or settings that affects this issue, but it's possible.

Here's my notes on debugging this so far:

Since the menubar is switched out when the window is made background, it's challenging to use an interactive, window-based debugger like XCode. I've been falling back to using print logging style debugging in the terminal, but that appears to show that we should be seeing a complete Edit menu, be we aren't seeing it for some reason.

I'm trying to find the place in code where we can intercept the creation of the "Emoji & Symbols" menu item -- anything that has the action @selector(orderFrontCharacterPalette:) -- and I can't find it. I tried overriding the init method of the GeckoNSMenuItem interface, and it wasn't getting hit there. Does that mean that the NSMenuItem is being initialized externally and added to the Edit menu somehow? I've not yet figured out how to test this theory.

Flags: needinfo?(dschubert)

Yeah, in a fresh profile that just popped open, I don't see the edit menu either.

But this is very cursed: If I run firefox --profile tmp --foreground, and immediately try to enter an emoji into the URL bar with cmd+ctrl+space, I get the emoji picker to work. If I click the "edit" menu item in menubar and then try to open the emoji picker in the still-focused URL bar, it no longer works.

The "immediately try to open the emoji picker without doing literally anything else" is what got the the regressor in mozregression.

Flags: needinfo?(dschubert)

This remains confusing. Based on my simpler STR in comment 14, I did my own mozregression and got Bug 1923666. Did a second mozregression and confirmed it. That was a one-line change in menu code that now is no longer even in the tree, so I can't even roll it back.

I'm going to mark Bug 1923666 as the regressor. I'm willing to continue owning this Bug, but I want Stephen to investigate as the author of what is perhaps the actual regressor. Stephen, would you please take a look?

Flags: needinfo?(spohl.mozilla.bugs)
Regressed by: 1923666
No longer regressed by: 1959023
See Also: → 1982840
Duplicate of this bug: 1987275

Fun fact: Click on Firefox's video PIP and the emoji picker will work again.

Seriously, this may help you find the bug. Reproduce:

  1. Click on another app to send Firefox to the background.
  2. Click on the input field -> the emoji picker isn't working. (CTRL+CMD+SPACE)
  3. Click on the Firefox video PIP and return to the input field -> the emoji picker is working again.
Duplicate of this bug: 1988402

FWIW, it seems that pressing just "fn" to bring up the emoji picker still works. So it might be there's no issue with the menu itself, but just those specific keybinds?

@julie In my case, this does not work with my keyboard. It might help to find / fix the bug. But should not be the solution. I hope for fixing the bug as soon as possible. CTRL + CMD + SPACE must work! Btw. it does not matter if I change the keybinding. It actually seems to be a bug in Firefox.

Btw. can you or someone else confirm my reproducibility of the issue (post above)? Short: Open another app to bring Firefox in background > try to open emojis & symbols picker with CTRL+CMD+SPACE > Not working > Click on Firefox Video PIP > Back to text field and try again > Works. Repeat.

Set release status flags based on info from the regressing bug 1923666

Assignee: bwerth → spohl.mozilla.bugs

This is somewhat unfortunate, but I couldn't find a better way to address this. There are two aspects to this fix:

  1. In order for SVG chicklets to appear in the context menu the first time it is opened, we have to set an nsMenuX to be rebuilt in its constructor (bug 1923666). However, this interferes with some menus, such as the Window and the Edit menu, since macOS adds its own menu items to these menus. This patch expands the fix for bug 1939346 for the Window menu to also include the Edit menu, where the Emoji picker is added as a menu item.

  2. Bug 1808223 addressed a regression due to a macOS bug where the emoji picker and the dictation menu item are added every time that a main menu bar is set for an app, but macOS 'forgets' to remove these items when switched away from one Firefox window to another and back again. One quirk about this is that if the user switches to another APP and back to the same Firefox window, macOS will not re-add these menu items to the edit menu again. So we need to avoid removing these problematic menu items in this situation. I was hoping to implement a fix that would simply remove duplicates after setting the NSApp.mainMenu, but if we do so then macOS will remove ALL added menu items and the emoji picker will disappear entirely from the Edit menu. So this appears to be the only way to properly fix this.

Pushed by spohl@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/2a29cd6d47f6 https://hg.mozilla.org/integration/autoland/rev/c1bc3fc9b645 Ensure that the emoji picker menu item doesn't disappear from the menu bar and that its associated shortcuts continue to work on macOS. r=mac-reviewers,bradwerth
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 145 Branch
QA Whiteboard: [qa-triage-done-c146/b145] [qa-ver-needed-c146/b145]
Flags: qe-verify+

:spohl, this might be risky for a release uplift request for the planned Fx144 dot release? What do you think?
Would it be safe for you to request uplift to ESR140 at least for 140.5.0esr? (it applies cleanly to ESR140)

Comment on attachment 9519414 [details]
Bug 1980815: Ensure that the emoji picker menu item doesn't disappear from the menu bar and that its associated shortcuts continue to work on macOS. r=#mac-reviewers

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is a frustrating usability bug with only non-obvious ways for a user to fix.
  • User impact if declined: The emoji picker on macOS is most conveniently launched by using one of the assigned keyboard shortcuts. However, due to this bug, not only do the shortcuts stop working when switching to another app and back to Firefox, but the emoji menu entry is missing from the main menu bar entirely and cannot be launched until the user switches to another Firefox window and back.
  • Fix Landed on Version: 145
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is a very narrow change to address the missing emoji picker. A similar fix has previously landed for macOS-supplied menu entries in the Window menu (bug 1642138).

Beta/Release Uplift Approval Request

  • User impact if declined/Reason for urgency: The emoji picker on macOS is most conveniently launched by using one of the assigned keyboard shortcuts. However, due to this bug, not only do the shortcuts stop working when switching to another app and back to Firefox, but the emoji menu entry is missing from the main menu bar entirely and cannot be launched until the user switches to another Firefox window and back.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: 1. Open a page with a text/input field, such as bugzilla.
  1. Click on another app to send Firefox to the background.
  2. Click on the input field in Firefox. Try to open the emoji picker using the keyboard shortcuts (Ctrl+Cmd+Space and Fn+e should both work).
  3. Confirm that the emoji and dictation menu entries are visible in the Edit menu in the menu bar.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is a very narrow change to address the missing emoji picker. A similar fix has previously landed for macOS-supplied menu entries in the Window menu (bug 1642138).
  • String changes made/needed: none
  • Is Android affected?: No
Flags: needinfo?(spohl.mozilla.bugs)
Attachment #9519414 - Flags: approval-mozilla-release?
Attachment #9519414 - Flags: approval-mozilla-esr140?

(In reply to Donal Meehan [:dmeehan] from comment #27)

:spohl, this might be risky for a release uplift request for the planned Fx144 dot release? What do you think?
Would it be safe for you to request uplift to ESR140 at least for 140.5.0esr? (it applies cleanly to ESR140)

I believe the risk to be minimal, especially since we landed a similar fix for menu entries in the Window menu before. I have filed uplift requests.

There have been a few different ways that have been mentioned in this bug to trigger this issue. If you could please double-check and confirm that this is fixed for your use case in current Nightly or Beta, I would appreciate it!

Flags: needinfo?(supercoolguy56911)
Flags: needinfo?(dschubert)
Flags: needinfo?(dagacc)

It seems to work. Thanks πŸ‘

Flags: needinfo?(dagacc)
QA Whiteboard: [qa-triage-done-c146/b145] [qa-ver-needed-c146/b145] → [qa-triage-done-c146/b145] [qa-ver-needed-c146/b145][uplift]

Yeah, seems to work. If it breaks again, I'll make noise.

Flags: needinfo?(dschubert)

Hello,

Verified fixed on Beta 145.0b2 using macOS 13.6 ARM and macOS 14.

QA Contact: acristea
Duplicate of this bug: 1996145

Comment on attachment 9519414 [details]
Bug 1980815: Ensure that the emoji picker menu item doesn't disappear from the menu bar and that its associated shortcuts continue to work on macOS. r=#mac-reviewers

Approved for 144.0.2

Attachment #9519414 - Flags: approval-mozilla-release? → approval-mozilla-release+

Hi,

The issue is verified fixed using Firefox 144.0.2 on macOS 13 ARM and macOS 14; tested by focusing another application (Chrome, UTM) and then focusing the Firefox browser window again.

Status: RESOLVED → VERIFIED
Attachment #9519414 - Flags: approval-mozilla-esr140? → approval-mozilla-esr140+

This is suggested wording. Please feel free to adjust.

Release Note Request (optional, but appreciated)
[Why is this notable]: The emoji picker on macOS now works consistently in Firefox
[Affects Firefox for Android]: No
[Suggested wording]: The emoji picker on macOS used to work intermittently in Firefox, especially after switching between applications. The emoji picker now reliably responds to keyboard shortcuts (by default, Ctrl+Cmd+Space and Fn+e) and appears as expected in the Edit menu in the main menu bar.
[Links (documentation, blog post, etc)]: n/a

relnote-firefox: --- → ?
Flags: needinfo?(supercoolguy56911)

A release note was already added when we shipped the 144.0.2 dot release
https://www.firefox.com/en-US/firefox/144.0.2/releasenotes/

QA Whiteboard: [qa-triage-done-c146/b145] [qa-ver-needed-c146/b145][uplift] → [qa-triage-done-c146/b145] [qa-ver-done-c146/b145] [uplift]
Regressions: 1997435
No longer regressions: 1997435
See Also: → 1997435

The issue is verified fixed on ESR 140.5 using macOS 13.6 ARM and macOS 14.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: