1989226 - Add Icons to Context Menus and Menu Bar Dropdowns on macOS 26 Tahoe

Status: RESOLVED WONTFIX

(Core :: Widget: Cocoa, enhancement)

Description

[lolrepeatlol]

Attachment: image.png

Icons within context menus and menu bar dropdowns are now part of macOS 26 Tahoe. Apple has started to implement these into Safari -- though I don't see them consistently applied in Safari's menu bar yet, they are present within Safari's context menus (Safari 26).

For improved context menu readability and continued consistency with the rest of macOS, icons should be implemented within Firefox's context menus and menu bar dropdowns, similar to Safari.

Comment 1

[Nishu Sheth [:nishu]]

Attachment: WIP: Bug 1989226 - Add Icons to Context Menus on macOS

Comment 2

[Nishu Sheth [:nishu]]

Attachment: WIP: Bug 1989226 - Add Icons to Context Menus and Menu Bar Dropdowns on macOS

Comment 3

[matthias koplenig [:metasieben]]

Is this change planned for all versions of macos?

Older versions do not "recommend" these icons, and seeing as they are received[1]
they might be removed again in 27.

[1] https://tonsky.me/blog/tahoe-icons/

Comment 4

[Stephen A Pohl [:spohl]]

While investigating bug 1154697 (Profile Manager NSSavePanel Cmd+V) and bug 2040809 (menu-bar Undo/Redo regression), an important finding emerged that should inform this bug's patch:

macOS 26 (Tahoe) auto-injects SF Symbol icons next to menu items whose action is a standard NSResponder selector with target=nil. We do not need to set NSMenuItem.image ourselves — AppKit does it as part of its menu-rendering pass, using the same SF Symbols Safari and other native apps display.

We can confirm this empirically because we've gradually opted into the auto-injection over three patches:

• Bug 1478347 (in widget/cocoa/nsMenuItemX.mm) special-cased menu_copy to use @selector(copy:) with target=nil so AppKit would expose the macOS "Copy" menu item to the Emoji picker / writing-tools sub-items in multi-language environments. As a side effect, on macOS 26 the Edit > Copy item automatically shows the system clipboard glyph — we never set an image.

• Bug 2036608 extended that wiring to menu_cut, menu_paste, menu_undo, menu_redo, menu_delete, menu_selectAll (all NSResponder selectors with target=nil). On macOS 26, those items also picked up their respective icons "for free" the moment that patch landed, with zero NSMenuItem.image code.

• Bug 2040809 then had to narrowly revert menu_undo / menu_redo to menuItemHit: dispatch because NSResponder's default undo: / redo: swallow the action when no NSUndoManager exists in the responder chain (Gecko uses its own TransactionManager). Side effect: macOS 26 stopped injecting the icons for Undo / Redo, because menuItemHit: is not one of the standard NSResponder Edit selectors. The follow-up in bug 2040844 keeps menu_undo / menu_redo on @selector(undo:) / @selector(redo:) and overrides those selectors on ChildView in nsCocoaWindow.mm to forward to menuItemHit: — restoring both the icons and the working menu-bar Undo/Redo.

Implications for this bug:

1. For every standard NSResponder selector we already wire (paste:, copy:, cut:, undo:, redo:, delete:, selectAll:), the icon is free. The patch shouldn't bother setting NSMenuItem.image for those.

2. The same approach should be the preferred path for any new Edit-menu-style item we want an icon on: route the action through the responder chain via a standard selector, and (if necessary) override that selector on ChildView the way bug 2040844 does. This is dramatically future-proof: Apple shipping new SF Symbols, new design refreshes, or even removing the icons in a later macOS, will follow our menu items automatically. Conversely, explicit NSMenuItem.image assignments lock us to a specific symbol name, will look outdated when Apple changes the system glyph, and will silently miss any future auto-injection of other menu items if AppKit broadens the heuristic.

3. Items that don't map to a standard NSResponder selector (custom context-menu actions, view-mode items, etc.) will still need explicit image assignment — that's where the WIP patches here should focus.

Open question worth keeping in mind: during testing we briefly saw the Paste menu item with no icon while Cut and Copy showed theirs, on the same Firefox window. The state cleared on a subsequent launch and we couldn't reproduce it deterministically. May be related to validateUserInterfaceItem: returning NO when the pasteboard is empty at menu-construction time, or just a stale cache state on our side. Worth watching while testing the icon patch.

Bug references for quick context:

• bug 1478347 — original menu_copy → @selector(copy:) wiring
• bug 2036608 — extension to the rest of the standard Edit menu items
• bug 2040809 — regression revert for menu-bar Undo/Redo (narrow)
• bug 2040844 — ChildView.undo:/redo: override that restores the icons + sheet undo
• bug 1154697 — Profile Manager NSSavePanel Cmd+V (which surfaced this whole investigation)

Comment 5

[Sören Hentzschel]

continued consistency with the rest of macOS, icons should be implemented within Firefox's context menus and menu bar dropdowns, similar to Safari.

Please note that Apple has removed most menu icons again in macOS Golden Gate.

Comment 6

[Haik Aftandilian [:haik]]

(In reply to Sören Hentzschel from comment #5)

continued consistency with the rest of macOS, icons should be implemented within Firefox's context menus and menu bar dropdowns, similar to Safari.

Please note that Apple has removed most menu icons again in macOS Golden Gate.

Closing as wontfix.