User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36

Steps to reproduce:

While "Developer Tools" window is not docked, if we try to open the dropdowns on the "Memory" tab, the list items are not displayed.

1. Launch Firefox
2. Open "Developer Tools"
3. Select the option to undock/show "Developer Tools" in a separate window
4. Switch to the "Memory" tab on "Developer Tools"
5. Using Mouse/Pointing device try to select one of the "View" options

Actual results:

The list items for dropdown "View" (or other dropdowns on the same tab like "Group By", and "Label By") do not appear.

Expected results:

The list items should appear as they do when the "Developer Tools" window is docked to the side of bottom of the main browser window.

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

Thanks for the report. This seems to affect select boxes in many panels: the performance panel, the debugger (method selector for XHR breakpoints...), the inspector (unit selector in the fonts panel).

This is already broken in 101, but seems to work in ESR. So there was a regression between 91 and 101.

Confirmed regressed by Bug 1744009

:emilio, since you are the author of the regressor, bug 1744009, could you take a look?
For more information, please visit auto_nag documentation.

Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.

The DevTools window was missing it, for example.

https://hg.mozilla.org/mozilla-central/rev/0c764d729423

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox102 to wontfix.

For more information, please visit auto_nag documentation.

This just adds the relevant element to the toolbox window for beta, to avoid uplifting a potentially-risky patch. Julian can you sanity-check the patch?

Approval Request Comment
[Feature/Bug causing the regression]: bug 1744009
[User impact if declined]: comment 0
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes (but this is a different fix, so no)
[Needs manual test from QE? If yes, steps to reproduce]: comment 0
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: not risky
[Why is the change risky/not risky?]: toolbox-window specific change, adding an element for the select menu to work. The patch in Nightly is more complete but riskier for uplift.
[String changes made/needed]: none

Comment on attachment 9282361 [details]
More scoped patch for beta.

We have already shipped our release candidate and it is a P2/S3 that regressed in 98. I think it can ride the 103 train.

For what it's worth the reduced patch was fine for DevTools, thanks again for working on this.
As Pascal said, given that it's not a recent regression, it's okay if it rides the trains. But maybe we should still uplift it to 102 ESR?

Yeah, I think we can still nominate the reduced patch for ESR102 for the next release :)

Reproduced this issue on an affected Nightly build from 2022-06-15, on Windows 10 x64 and following the STR from Comment 0.
Verified as fixed on Firefox 103.0b2 (20220628190840) on Wind 10, macOS 10.14 and Ubuntu 22.04.

Waiting for the issue to be fixed in Firefox 102esr.

[Tracking Requested - why for this release]:this bug affect to Firefox 102.0esr and Thunderbird 102 (Bug 1777285).

(In reply to [Back July 11] Ryan VanderMeulen from comment #12)

Yeah, I think we can still nominate the reduced patch for ESR102 for the next release :)

Given comment 14, do we want the reduced patch or the full patch? I don't think the full patch is terribly risky fwiw. It has a lot of test changes but the patch itself is relatively simple.

We should do something about this bug for the 102.1esr release. Given the Thunderbird impact and lack of reported regressions with the original patch, let's go ahead and move forward with an approval request on it.

Comment on attachment 9281798 [details]
Bug 1774378 - Make select code harder to mess up. r=Gijs,mconley

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Affects multiple combobox menus in thunderbird, and some in Firefox
• User impact if declined: see the see also field + comment 0
• Fix Landed on Version: 103
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): Not a super-minimal patch, but it's simple (mostly removes code actually) and well-understood.

Comment on attachment 9281798 [details]
Bug 1774378 - Make select code harder to mess up. r=Gijs,mconley

Approved for ESR102.1, thanks.

https://hg.mozilla.org/releases/mozilla-esr102/rev/cfe524975e83

Verified as fixed on Firefox esr102.1 (20220714135928 - treeherder build) on Wind 10, macOS 10.14 and Ubuntu 21.04.