Hi all, over the past weeks/months I've been working on making Firefox use native context menus on macOS, rather than our historical non-native emulations. This work is tracked in bug 34572. As of a few days ago, native context menus are now ready for testing on Nightly and most known bugs are fixed. Native context menus are currently behind two off-by-default prefs: `browser.proton.enabled` and `widget.macos.native-context-menus`, and we have bug 1700109 and bug 1700679 for enabling those prefs by default. Description: This is a platform change to use the Cocoa classes `NSMenu` and `NSMenuItem` for all Firefox context menus. Other types of menus, such as toolbarbutton dropdown menus, bookmark toolbar folder dropdowns, or <select> popups, will remain non-native for now. The menu's root `NSMenu` [is opened using `-[NSMenu popUpContextMenu:withEvent:forView:]`](https://searchfox.org/mozilla-central/rev/be413c29deeb86be6cdac22445e0d0b035cb9e04/widget/cocoa/NativeMenuMac.mm#289). The `NSMenu` contents are created based on the XUL structure inside the `<menupopup>`, i.e. based on the `<menupopup>`, `<menuitem>`, `<menu>` and `<menuseparator>` elements. Interactions with the native menu are mirrored into XUL-land in such a way to keep existing front-end code working. For example: - Opening and closing the menu fires `popupshowing`/`popupshown`/`popuphiding`/`popuphidden` events as expected. - Open menus have `menupopupElement.state == "open"`. - Hovered menu items have the `menuactive` attribute set. - When a menu item is clicked / activated, its command event fires. - When a checkbox/radio menu item is activated, the `checked` attribute is updated as appropriate. - Dynamic DOM changes during the `popupshowing` event are reflected in the menu contents. And some DOM changes (such as changes to the menuitem label) are reflected even if they change while the menu is open. How do we test this? 1. Set the two prefs mentioned above. 2. Right-click to open a context menu, anywhere where Firefox uses context menus. When will this ship? I'm trying to ship this in 89 because it's considered part of the MR1 release. Tracking bug/issue: bug 34572 Design documents (e.g. Product Requirements Document, UI spec): bug 34572 comment 22 (somewhat outdated) Engineering lead: Markus Stange Product manager: Martin Balfanz Please describe the accessibility guidelines you considered and what steps you've taken to address them: I've skimmed them but they don't seem particularly relevant, given that this is a rather low-level change. Describe any areas of concern to which you want the accessibility team to give special attention: My initial expectation was that native context menus should give us "native accessibility" for free, because we'll be behaving more like any other native macOS app, and not so much like a special snowflake. So I wasn't expecting much trouble. However, as shown by bug 1703482, clearly there is at least some amount of trouble. Other areas that deserve special attention are: - Not sure if relevant, but we should make sure that focus works as expected during menu interactions. - If there are "notifications" for various menu state changes, we should make sure that these fire as appropriate. And we should make sure we're not double-firing them. For example, since we mirror state changes from the native menu into Gecko, I could imagine that both macOS and Gecko may try to notify for certain changes.
Bug 1703617 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Hi all, over the past weeks/months I've been working on making Firefox use native context menus on macOS, rather than our historical non-native emulations. This work is tracked in bug 34572. As of a few days ago, native context menus are now ready for testing on Nightly and most known bugs are fixed. Native context menus are currently behind two off-by-default prefs: `browser.proton.enabled` and `widget.macos.native-context-menus`, and we have bug 1700109 and bug 1700679 for enabling those prefs by default. Description: This is a platform change to use the Cocoa classes `NSMenu` and `NSMenuItem` for all Firefox context menus. Other types of menus, such as toolbarbutton dropdown menus, bookmark toolbar folder dropdowns, or <select> popups, will remain non-native for now. The menu's root `NSMenu` [is opened using `-[NSMenu popUpContextMenu:withEvent:forView:]`](https://searchfox.org/mozilla-central/rev/be413c29deeb86be6cdac22445e0d0b035cb9e04/widget/cocoa/NativeMenuMac.mm#289). The `NSMenu` contents are created based on the XUL structure inside the `<menupopup>`, i.e. based on the `<menupopup>`, `<menuitem>`, `<menu>` and `<menuseparator>` elements. Interactions with the native menu are mirrored into XUL-land in such a way to keep existing front-end code working. For example: - Opening and closing the menu fires `popupshowing`/`popupshown`/`popuphiding`/`popuphidden` events as expected. - Open menus have `menupopupElement.state == "open"`. - Hovered menu items fire `DOMMenuItemActive` events. - When a menu item is clicked / activated, its command event fires. - When a checkbox/radio menu item is activated, the `checked` attribute is updated as appropriate. - Dynamic DOM changes during the `popupshowing` event are reflected in the menu contents. And some DOM changes (such as changes to the menuitem label) are reflected even if they change while the menu is open. How do we test this? 1. Set the two prefs mentioned above. 2. Right-click to open a context menu, anywhere where Firefox uses context menus. When will this ship? I'm trying to ship this in 89 because it's considered part of the MR1 release. Tracking bug/issue: bug 34572 Design documents (e.g. Product Requirements Document, UI spec): bug 34572 comment 22 (somewhat outdated) Engineering lead: Markus Stange Product manager: Martin Balfanz Please describe the accessibility guidelines you considered and what steps you've taken to address them: I've skimmed them but they don't seem particularly relevant, given that this is a rather low-level change. Describe any areas of concern to which you want the accessibility team to give special attention: My initial expectation was that native context menus should give us "native accessibility" for free, because we'll be behaving more like any other native macOS app, and not so much like a special snowflake. So I wasn't expecting much trouble. However, as shown by bug 1703482, clearly there is at least some amount of trouble. Other areas that deserve special attention are: - Not sure if relevant, but we should make sure that focus works as expected during menu interactions. - If there are "notifications" for various menu state changes, we should make sure that these fire as appropriate. And we should make sure we're not double-firing them. For example, since we mirror state changes from the native menu into Gecko, I could imagine that both macOS and Gecko may try to notify for certain changes.