Search Mode Switcher menu items should not have explicit access keys (first letter shouldn't be underlined) so that multiple panel items can share the same implied access key
Categories
(Firefox :: Address Bar, defect, P1)
Tracking
()
People
(Reporter: oardelean, Assigned: dao)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: regression, Whiteboard: [sng][mcab-hnt-followon])
Attachments
(3 files)
Notes
- Please see the attached screenshot for more details.
- Reproducible with both Proton and Nova.
- Could not reproduce on macOS so far.
Found in
- Nightly 157.0a1;
Affected versions
- Nightly 157.0a1;
Tested platforms
- Windows 11;
- Ubuntu 22;
- macOS 13;
Affected platforms
- Windows 11;
- Ubuntu 22;
Unaffected platforms
- macOS 13;
Steps to reproduce
- Launch Firefox.
- Open the Search Mode Switcher.
Expected result
- Search engines are displayed properly.
Actual result
- Search engines listed have the first letter underscored.
Regression range
- last good: 2026-07-10
- first bad: 2026-07-11
- pushlog: https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=734668e5d008b174543e28f33dacc14ca02369f9&tochange=f43c4e4bb21ddccd72c7b1df9eb422779182f701
- potentially regressed by: bug 2051148
Comment 1•24 days ago
|
||
Set release status flags based on info from the regressing bug 2051148
:mbeier, since you are the author of the regressor, bug 2051148, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Updated•24 days ago
|
Comment 2•22 days ago
|
||
This is a mnemonic for the key that can be pressed to select each item (also called its accesskey). It can be disabled by setting ui.key.menuAccessKey to 0 but it's intentionally on by default on Linux.
One thing I just realized is that imnemonics aren't visible in the newtab searchbar because panel-list uses XUL labels to render them (the accesskey still works). Dao do you think this inconsistency should be addressed?
| Assignee | ||
Comment 3•7 days ago
|
||
I believe these are implied first-letter access keys, and therefore shouldn't get the underline.
Updated•7 days ago
|
| Assignee | ||
Comment 4•7 days ago
|
||
Oh, these aren't auto accesskeys, but they should be. Same reasoning as in bug 2071753.
| Assignee | ||
Updated•7 days ago
|
| Assignee | ||
Updated•7 days ago
|
| Assignee | ||
Comment 5•7 days ago
|
||
The Smartbar's mention panel moves focus to its editor before this runs, which is why the check asks what kind of element has focus and not where it sits; a XUL panel opened by mouse leaves focus on the body and keeps the letters.
| Assignee | ||
Comment 6•7 days ago
|
||
| Assignee | ||
Updated•6 days ago
|
Updated•5 days ago
|
| Assignee | ||
Updated•4 days ago
|
Comment 8•4 days ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/7e4a59fede40
https://hg.mozilla.org/mozilla-central/rev/bb67d5fdf7ce
Updated•2 days ago
|
| Reporter | ||
Updated•2 days ago
|
| Reporter | ||
Comment 9•1 day ago
|
||
Reproducible on a 2026-09-02 Firefox Nightly build on Windows 10.
Verified as fixed on Firefox Nightly 159.0a1 and Firefox 158.0b1 on Windows 10, Ubuntu 22, macOS 13.
Comment 10•1 day ago
|
||
The patch landed in nightly and ESR is affected.
:dao, please make an uplift decision for ESR:
- For ESR, nominate the patch for the appropriate ESR uplift approval if the fix should be included in ESR, or set the ESR status flag(s) to
wontfixif an uplift isn't needed. Each affected ESR release needs a decision.
See Requesting an Uplift for documentation on how to request an uplift.
For more information, please visit BugBot documentation.
| Assignee | ||
Updated•1 day ago
|
Description
•