Open Bug 2032378 Opened 1 month ago Updated 1 month ago

The `Use other...` action is not displayed while the Select helper application window is opened

Categories

(Firefox :: Settings UI, defect, P3)

Desktop
All
defect

Tracking

()

Tracking Status
firefox-esr115 --- unaffected
firefox-esr140 --- unaffected
firefox149 --- unaffected
firefox150 --- disabled
firefox151 --- disabled
firefox152 --- affected

People

(Reporter: atrif, Unassigned)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [recomp])

Attachments

(1 file)

Attached image actions_use_other.gif

Found in

  • 151.0a1 (2026-04-15)

Affected versions

  • 150.0a1 (2025-04-15)

Tested platforms

  • Affected platforms: Windows 11, macOS 26, Ubuntu 24
  • Unaffected platforms: none

Steps to reproduce

  1. Inside Settings, change WebP Image to Always Ask.
  2. Reopen the dropdown and choose Use other… and observe the Action.

Expected result

  1. WebP Image is Use other...

Actual result

  • WebP Image is Open in Nightly.

Regression range

Additional notes

  • Attached a screen recording.
  • The Use other... option is not displayed when choosing options using the keyboard key.
  • Note that bug 2018560 was fixed and the previously chosen option is correctly displayed after the Select Helper Application window is closed.

:mkennedy, since you are the author of the regressor, bug 1972076, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(mkennedy)

This is due to moz-select forcing a change of the selected value when clicking "Use other". That's a problem in this case, because the moz-select value doesn't need to change just because "Use other" is clicked. It should only change after the user selects an app from the dialog.

To workaround this, after moz-select changes the value to a new selection after "Use other" click, there is a hack in place to temporarily change the value back to a historical selection while the dialog is open and then reverts back to its originally selected value after closing the dialog. That's why an unrelated value is temporarily shown while dialog is open (in original video).

A couple of options I see here to resolve this:

  1. update moz-select to allow Applications code to stop propagation of the click event to stop the value from changing until dialog is closed (this is what the old code was doing before moz-select was used) or
  2. update Applications code to somehow stop moz-select from changing the value initially and only change it if a new app in the dialog is selected

I'm in favor of 1. 2 may not be possible and would just be another hack. To do 1, it looks like clicking a moz-select option calls redispatchEvent which swallows the original event and creates a new one. Having no access to the original event is likely what is preventing Applications code from stopping its propagation.

Flags: needinfo?(mkennedy)
Severity: -- → S4
Priority: -- → P3

Pref: browser.settings-redesign.enabled

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

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

Attachment

General

Created:
Updated:
Size: