1850071 - On MacOS, widget.macos.native-context-menus does not enable native context menus for <select> elements on webpages.

Status: RESOLVED WONTFIX

(Core :: Widget: Cocoa, enhancement)

Description

[OBlockWarMachine]

Attachment: Screenshot 2023-08-24 at 8.24.32 PM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

Set widget.macos.native-context-menus in about:config to true, and view a <select> element dropdown menu like on this page: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_select.

Actual results:

With the flag set to true, it should show a native dropdown / context menu, but instead it shows a non-native one, which can be selected in the browser toolbox and have its looked changed with CSS.

Expected results:

Display a natvie context menu.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Stephen A Pohl [:spohl] (OOO until 1/2)]

This is not controlled by the widget.macos.native-context-menus pref, nor is this a context menu. This is controlled by the widget.non-native-theme.enabled pref and by setting this pref to false, it will display a native select menu.

Comment 3

[OBlockWarMachine]

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

This is not controlled by the widget.macos.native-context-menus pref, nor is this a context menu. This is controlled by the widget.non-native-theme.enabled pref and by setting this pref to false, it will display a native select menu.

Can this be reopened? I changed widget.non-native-theme.enabled to false and it still shows a non-native select menu, the same as the original photo.

Comment 4

[Stephen A Pohl [:spohl] (OOO until 1/2)]

We are moving away from native widgets, and the ability to disable non-native widgets will be removed as well (see bug 1848899). Marking this bug as wontfix instead.

Comment 5

[OBlockWarMachine]

(In reply to Stephen A Pohl [:spohl] (OOO until 10/23) from comment #4)

We are moving away from native widgets, and the ability to disable non-native widgets will be removed as well (see bug 1848899). Marking this bug as wontfix instead.

Can you elaborate on this? which widgets would become non-native? Weren't native right click context menus enabled for macOS a few years ago after that FR was open for over 20 years? It doesn't make sense that if the look of a dropdown menu is going to be the same for all <select> elements then its going to be a non-native / psuedo-native looking one instead of a native one.

Comment 6

[Stephen A Pohl [:spohl] (OOO until 1/2)]

(In reply to Oneechan69 from comment #5)

(In reply to Stephen A Pohl [:spohl] (OOO until 10/23) from comment #4)

We are moving away from native widgets, and the ability to disable non-native widgets will be removed as well (see bug 1848899). Marking this bug as wontfix instead.

Can you elaborate on this? which widgets would become non-native? Weren't native right click context menus enabled for macOS a few years ago after that FR was open for over 20 years? It doesn't make sense that if the look of a dropdown menu is going to be the same for all <select> elements then its going to be a non-native / psuedo-native looking one instead of a native one.

Anything in-content is non-native, looking identical across platforms. Context menus will remain native as they're not in-content.

Comment 7

[Markus Stange [:mstange]]

The select popup isn't currently rendered in-content; the items are sent to the parent process and it's the parent process that currently creates the XUL menu.

Other browsers use native menus for the <select> popup, so there would certainly be precedence for using a native menu.

However, native menus don't deal with a long list of items. There is no draggable scroll bar and no search field. For a while, we had a project (I can't find the bug right now) to move the rendering of <select> popups into content so that it's easier to make long lists perform well. But I don't know what the current status of that project is or if the thinking has changed.

Comment 8

[Stephen A Pohl [:spohl] (OOO until 1/2)]

(In reply to Markus Stange [:mstange] from comment #7)

The select popup isn't currently rendered in-content; the items are sent to the parent process and it's the parent process that currently creates the XUL menu.

To avoid misunderstandings: I was referring to page content, not content processes.