The `Use other...` action is not displayed while the Select helper application window is opened
Categories
(Firefox :: Settings UI, defect, P3)
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)
|
600.98 KB,
image/gif
|
Details |
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
- Inside Settings, change
WebP ImagetoAlways Ask. - Reopen the dropdown and choose
Use other…and observe the Action.
Expected result
WebP ImageisUse other...
Actual result
WebP ImageisOpen in Nightly.
Regression range
- Happens after bug 2018560.
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 Applicationwindow is closed.
Updated•1 month ago
|
Comment 1•1 month ago
|
||
: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.
Comment 2•1 month ago
•
|
||
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:
- 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
- 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.
Updated•1 month ago
|
Comment 3•1 month ago
|
||
Pref: browser.settings-redesign.enabled
Comment 4•1 month ago
|
||
Set release status flags based on info from the regressing bug 1972076
Description
•