Closed Bug 34572 Opened 24 years ago Closed 3 years ago

Use native context menus on Mac OS

Categories

(Core :: Widget: Cocoa, enhancement, P1)

All
macOS
enhancement

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
thunderbird_esr78 --- wontfix
firefox-esr78 --- wontfix
firefox88 --- wontfix
firefox89 --- fixed
firefox90 --- fixed

People

(Reporter: mpt, Assigned: mstange)

References

(Depends on 5 open bugs, Blocks 2 open bugs)

Details

(Keywords: helpwanted, platform-parity, Whiteboard: [proton-context-menus][mac:mr1])

Mozilla on MacOS is using native main menus -- the XUL menu items are being 
translated into native menu structures, allowing Mozilla to use the Mac's main 
menu bar.

Why couldn't this be done with context menus as well? As far as I know, Web apps 
don't have style access to (or even knowledge of) context menus, so the usual 
skinnability arguments are not an issue. Using native menus would improve 
internal consistency between Mozilla main menus and context menus (and between 
Mozilla and other MacOS apps), as well as solving quite a few open bugs about 
MacOS popup menus.

Implementing this could probably borrow heavily from the code already written for 
making the main Mac menus.
i can't argue, but it's a time thing.
Status: NEW → ASSIGNED
Keywords: helpwanted
Target Milestone: --- → M20
*** Bug 37795 has been marked as a duplicate of this bug. ***
Keywords: pp
Blocks: 39375
Blocks: 39403
No longer blocks: 39375
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M20 → Future
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.
QA Contact: sairuh → jrgm
Blocks: 7297
How easy/hard would this be?
I believe the following behavior is caused by this bug:

I have to "Turn off Contextual Menus in Mozilla 0.7" to see Mozilla's contextual
menus -- otherwise I get the "default" MacOS contextual menu (Help, Application
Menu, Refresh menus)
Severity: normal → enhancement
OS: All → Mac System 8.5
Summary: Use native context menus on MacOS → Use native context menus on Mac OS
The behavior being described by akt@yahoo.com above is caused actually by Apple
Data Detectors, an old software set that used AppleScript to open URLs embedded
in plain text. Its special contextual menus are available in all applications by
default, and you have to manually turn it off in apps that you don't want. It's
not relevant to this bug, as far as I can tell. (While I'm here, I'd like to
throw in my support for using the Mac's native menus.)
Blocks: 13185
No longer blocks: 13185
just make sure the native menus still come up if the contextual menus extension
is not pressent. i for one loath that damnable thing--apple decided to wipe out
control key alias dragging, okay that was defacto, but not official, but
removing command-option dragging to copy and align? that dated back as far as i
have used mac os.

not that we needed contextual menus, mind you. oh well, maybe someday someone
will do something useful with them (rather than converting a working system,
xul, in a way that might break it (maybe this bug should at least depend on bug
51142).
does this block bug 13185 ?

-matt
Blocks: 13185
Depends on: 118025
Depends on: 118296
No longer depends on: 118296
Does this bug affect OS X? If not, it should be WONTFIX.
It does affect Mac OS X.
*** Bug 196611 has been marked as a duplicate of this bug. ***
OS: Mac System 8.5 → MacOS X
Not having standard MacOS contextual menus means that Chronos Software's
StickyBrain does not function with Mozilla at all, and thus significantly
affects the user's ability to use StickyBrain for its intended purpose.

Mozilla also needs to recognize AppleScript (I know Camino doesn't...)
> Mozilla also needs to recognize AppleScript (I know Camino doesn't...)

Sure they do. There isn't much support, but there's some. What do you need?
*** Bug 240124 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0mac?
*** Bug 239036 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0mac?
Blocks: 262956
Blocks: 101472
No longer blocks: 262956
Blocks: macmeta
I've started to work on this..

So far, i have an issue: DrawThemeMenuItem needs the menu rect (in addition to
the menuitem rect); how can i achieve it?
I bet you can get away with using the same rect for both. I suspect OS 9's
beveled edges were mainly what made this important.
(In reply to comment #18)
> I bet you can get away with using the same rect for both. I suspect OS 9's
> beveled edges were mainly what made this important.

Probably not, even HITheme api (10.3+) thinks it needs this information.
(In reply to comment #17)
> I've started to work on this..

This report is marked as HELPWANTED . Do you have any design documentation?
Is there any way to speed your efforts on this 5 year old bug?
Assignee: mikepinkerton → joshmoz
Status: ASSIGNED → NEW
Assignee: joshmoz → nobody
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Fixing this should fix quite a few other bugs, including future OS style changes, so yes please! 

This bug should block Bug 565518.
No longer blocks: 101472
Component: XUL → Widget: Cocoa
Hardware: PowerPC → All
See Also: → 1656301
See Also: → 1668119

I have started looking into this a bit.

I think the outline of the work would be roughly the following:

  • Decide which of our non-native menus we want to be native. I'm aware of the following categories:
    • Context menus
    • <select> popups
    • Bookmarks folders in the bookmarks toolbar
    • (Other types of panels / popups, such as arrow panels or tooltips, are out of scope for this bug.)
  • Decide what to do about various cases where our fake menus have "extra powers" compared to native menus. More on this below.
  • Create an API in widget/cocoa that allows opening a menu at a given coordinate for a given menupopup DOM node. We already have similar APIs for the main menu bar, for the application menu and Dock menu, and for menus for system status bar icons.
  • Hook into the various DOM APIs and nsXULPopupManager APIs that open menus, and call the new API on macOS instead of opening a fake menu.
  • Implement various custom menu item NSView subclasses for various special things (see below).
  • Make sure the various events that our front-end code expects are fired appropriately, e.g. popupshowing, popupshown, popuphiding, popuphidden.
  • Make sure DOM modifications are handled appropriately.
  • Make sure any custom menu items are accessible.
  • Check for performance problems. Maybe avoid layout work for native menus by making the "fake" menupopup display:none.
  • Deal with fallout in our automated tests. Any test that wants to interact with a context menu programmatically probably needs to disabled on macOS.

Notes on customizability

Native menus allow for a certain degree of customization by the app, via custom NSViews that are shown instead of menu items. So that means, for each horizontal row in a menu, we have the choice between two options:

  • A native menu item, which can have a label, an icon, a checkmark, a submenu, and a shortcut key annotation. These menu items are displayed with the native style for the OS. Their styling cannot be customized, but we also do not need to maintain them because they automatically adopt the updated look of any new macOS versions. (Edit: As noted by Ken below, it is possible to set custom text styling by using an NSAttributedString as the label.)
  • Or a custom view. These views occupy the full width of the menu, and a custom height. They can have arbitrary content and user input handling. Any text styling, hover effects, click handling, flashing effects etc needs to be implemented manually. If there are visual elements in custom views that are intended to match the OS native look, then the code for these visual elements needs to be updated whenever a new macOS version with an updated look is released.

Notes on "extra powers"

I'm aware of three features our fake menus have, which I don't think we can replicate in native menus:

  • Handling of arbitrary modifier keys when clicking menu items: For example, if you click a bookmarks folder in the Bookmarks toolbar to display the folder contents in a menu, and then hold the Cmd key while clicking a bookmark item, the item will load in a new tab. If you try the same in a native menu, for example in the Bookmarks menu from the menubar, then the Cmd key is ignored and the clicked bookmark will open in the current tab. Edit: This appears to be wrong, see the comments below. It looks like we can handle arbitrary modifier keys on native menu items.
  • "Menus on menus": For example, if you click a bookmarks folder in the Bookmarks toolbar, and then right-click a bookmark in the menu, you get a context menu that is displayed on top of the bookmarks folder popup. This is not possible with native menus - you cannot stack native menus, and you cannot right-click native menu items. (Or rather, right-clicking a native menu item will activate that item.)
  • Drag and drop of menu items: In bookmarks folder menus from the Bookmarks Toolbar, you can move and reorder bookmarks using drag and drop, even across different folders and submenus. This is not possible in native menus.

For these reasons, I think we should keep using custom menus for bookmarks folders in the Bookmarks Toolbar. We may want to update their styling to be explicitly different from native menus, so that users can have the right expectations for what they can do with them.
Also, for right-click context menus inside the custom bookmark folder menus, we can definitely use a native menu for the context menu.
As an alternative, we could decide to drop all this extra functionality on macOS. For example, Safari doesn't let you do any of the abovementioned things in their bookmarks toolbar.

Notes on "special things"

Most of our context menus only use basic menu elements and should easily work as native menus. However, we would need custom NSView implementations for the following:

  • For context menus:
    • The main content area context menu has a row at the top that shows four big icons: back, forward, refresh, bookmark. If we want to keep this custom icon row, we cannot use native menu items for these buttons, but we can implement the icon row with a custom view. This will require manually handling hover effects (including OS-specific visual styling of those hover effects) and click handling, including the flashing animation when an icon is clicked. The rest of the menu can be standard menu items.
  • For <select> popups:
    • If we decide to use native menus for <select> popups, we will probably need custom views for <optgroup> headers, and for items with custom styling (fonts, font styles, text color, background color). It's worth looking at Chrome's code for this (I haven't done that yet).
  • For bookmark folders from the bookmarks toolbar:
    • If we really want to use native menus for them, and keep their current feature set, then we'd need to do a ton of custom work here. I recommend against it. Let's keep using fake menus for them for now.

Excellent analysis. One comment:

“ If you try the same in a native menu, for example in the Bookmarks menu from the menubar, then the Cmd key is ignored and the clicked bookmark will open in the current tab.”

There is definitely some support for holding modifiers in native menus in the main menu bar at least. E.g. go to the Finder and open the File menu, then hold down Control, Option or Shift and observe the menu items change.

Is it possible that the issue here is more specific? That you can’t hold down Cmd and get a different behavior?
Maybe the simpler fix there is to map the behavior to Opt rather than Cmd (that’s the key I would expect to use to modify behavior).

(In reply to Andrew Thompson from comment #23)

Maybe the simpler fix there is to map the behavior to Opt rather than Cmd (that’s the key I would expect to use to modify behavior).

That definitely sounds like a good option to consider!

Markus, that's a great start. A couple thoughts (as a Mac developer who has fought with custom menus before):

  • You can handle modifier keys from stock menu items. I think Firefox should be improved to support cmd=newtab in the menu bar Bookmarks menu, as you suggest. Safari, in fact, supports exactly that feature! No need for custom menu items here, thankfully.

  • "Menus on menus" is such a strange interaction I wasn't aware Firefox did this. I tried it just now, and it's broken in several ways: the drawing is wrong, the mouse handling is wrong, and even keyboard shortcuts light up (but don't do anything) when it's open. It's downright hard to highlight or choose a menu item here just using the mouse normally. I've never seen any other Mac application have "menus on menus", and it breaks one of the most common standard menu operations (to be able to right-click on a menu item to choose it), so I would not be at all sad to see this removed.

Still, I do see value in being able to see a bookmark in a menu and go directly to editing it, if a more Mac-like way could be found. A common method I tend to see for "show me this in context" is holding down command while choosing a menu item (e.g., holding command while selecting an app from a folder's menu in the dock shows that app in the Finder rather than launching it), but unfortunately "command" is already used for "open in new tab". (Maybe "option"? In Safari, option always means "download", but it seems to be unused in Firefox. I don't know what the overall design for modifier keys in Firefox is.)

  • It's true that if you use a custom NSView, you take on responsibility for all drawing and event handling, which is a pain. In my own application, I took a middle path: NSMenuItem has an "attributedTitle" property for using an NSAttributedString as its label. This makes it easy to make an ordinary menu item with a special font, or even insert images (with transparency) in the middle of the text. It's much easier than a custom NSView, as you don't have to re-implement all of the event handling by hand, or do extra work each year to support OS visual upgrades.

That's awesome feedback, thanks a lot!

Let me provide an opposing perspective: as a heavily cross-platform user across Mac, Windows and sometimes even Linux, I'd be annoyed if the bookmarks toolbar supported different subsets of features on different platforms. Right clicking on a bookmark anywhere and having the same context menu actions on it is the most natural thing to me and I wouldn't like it taken away.

I'm a multiplatform guy (using Windows PC and MacBook Air with macOS daily) and for me more annoying is having ugly context menu that does not fit to the OS (and now even more annoying, one that does not support dark mode).

If we get native context menus, I very much hope to be given the option to deny extensions access to the context menu. As is I have to use the following to be able to maintain a sane context menu.

#context-media-eme-learnmore + menuseparator,
#context-media-eme-learnmore + menuseparator ~ *,
 {
     display: none !important;
 }

All right folks, let’s keep the rest of this bug focused on the implementation. The first step will only be about context menus anyway, and no loss of functionality is expected. If we do decide to change anything about the bookmarks toolbar folder implementation, it will happen later and in a different bug. I will link to that bug here once we get to that stage. No more advocacy comments please.
As for the add-on entries in context menu issue, yes, the userChrome CSS workaround from comment 29 will probably not work on native context menus. We can file a new bug to determine whether that’s something we want to support.

Whiteboard: [proton-contextmenu]
Whiteboard: [proton-contextmenu] → [proton-context-menus]

I'm pulling the Firefox source code now to look into this, but would it make more sense for us to consider Photon-themed context menus instead of going the native AppKit route? Greater UI consistency within the app seems like an admirable goal, and it'd give us flexibility to more easily incorporate nonstandard components like the forward/back/bookmark controls, as well as the userChrome CSS workaround from comment 29.

Hi Mike! We have considered it, but decided to go with native context menus on MacOS. (I don't have the full justification, but to me they just feel more like a thing that should be native… :)

Thanks for the comment!

I'm starting to work on this now.

Quick status update:

  • For now, only context menus will become native.
  • Bookmark folder dropdowns will be styled in a Firefox-specific (non-native) way and retain their full functionality. This was decided with the involvement of the UX team.
  • <select> popups may become native at some point in the future but will stay non-native for now.
Assignee: nobody → mstange.moz
Status: NEW → ASSIGNED
Target Milestone: Future → ---
Depends on: 1691213
Depends on: 1691861
Depends on: 1692669
Whiteboard: [proton-context-menus] → [proton-context-menus][mac:mr1]

Regarding <select>, please see also the bug 1571386.

As per guidance from Vicky, for tracking, we're marking all the bugs that people are working on as P1.

Priority: P3 → P1
Depends on: 1694853
Depends on: 1698662
Depends on: 1698668
Depends on: 1698997
Depends on: 1699551
Depends on: 1699582
Depends on: 1699792
Depends on: 1680177
Depends on: 1700679
Depends on: 1700706
Depends on: 1700710
Depends on: 1700713
Depends on: 1700715
Depends on: 1700724
Depends on: 1700727
Depends on: 1700732
Depends on: 1700822
Depends on: 1701085
Depends on: 1701243
Depends on: 1702041
Depends on: 1702129
Depends on: 1702288
No longer depends on: 1702288
Depends on: 1702387
Depends on: 1702633
Depends on: 1702664

Native context menus are now ready for testing on Nightly; all known bugs are fixed. To enable native context menus on Nightly, set these two prefs to true: widget.macos.native-context-menus and browser.proton.enabled

Please file any bugs you find in the Widget:Cocoa component and make them block this bug.

Thanks!

Depends on: 1703272
Depends on: 1703482
Depends on: 1703617
Depends on: 1703927
Depends on: 1703930
Depends on: 1704127
Depends on: 1704474
Depends on: 1703518
Depends on: 1704883
Depends on: 1704972
Depends on: 1705157
Blocks: 1687055
Depends on: 1706433
Depends on: 1706966
No longer depends on: 1702664
Depends on: 1705120
Depends on: 1707204
Depends on: 1707652
Depends on: 1707869

Bug 1700679 enabled native context menus by default on Nightly (Firefox 90), so this bug is now fixed!

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch

👏👏👏

Depends on: 1704102

Fixed by uplift in 89 beta 8

Blocks: 1710459
Depends on: 1710507
Depends on: 1710583
No longer depends on: 1710583

Greetings all! Firstly I just want to say I am very happy to see this long standing bug fixed. Trying out Nightly all looks so much better than the Firefox custom context menu so excellent job!

One thing I noticed was that the "Look Up" feature is not currently supported/implemented in the context menu (at least as of 90.0a1 (2021-05-24)). Is this something that/will be added before release in stable?

I am a huge user of the "Look Up" feature and I feel it is something macOS users expect to see when right clicking a word in the browser.

Hey Morgan, after a quick search I found this ticket bug 1116391. You can follow it by hitting the "Follow" button at the top. You can also add your vote. I saw that the last two comments were already marked as "me-too", so adding another one of those won't do much good ;) Hope that helps a bit.

are we sure that the person who created the bug is still alive? I would like to send a gift to your house.

👋

Reporting bugs is almost always easier than fixing them. So no gift necessary — all credit here is due to Markus, and to others who worked on dependencies. Thank you and well done.

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