AppMenu FxA "Show more tabs" option does not work using keyboard only
Categories
(Firefox :: Menus, defect, P2)
Tracking
()
Accessibility Severity | s2 |
People
(Reporter: ailea, Assigned: cmkm)
References
(Blocks 2 open bugs)
Details
(Keywords: access, Whiteboard: [proton-hamburger-menu][priority:2c][fidefe-quality-foundation])
Tested with:
Nightly 88.0a1 (2021-03-10)
Tested on:
Windows 10
MacOS 11
Preconditions:
In about:config, set browser.proton.enabled = true
Steps:
- Launch firefox and sign in into FxA using 2 devices.
- Open more than 25 tabs on one device and sync tabs with another devices.
- Using the keyboard only navigate to the "Show More Tabs" option and press enter/space in order to expand the list of synced tabs.
Actual result:
The hamburger menu is closed/dismissed.
Expected result:
The list of all synced tabs should be expanded.
Note: The issue is reproducible both with and without Proton enabled.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 1•4 years ago
|
||
This is pretty severe for those users who do encounter it (no way to access the 26th or later sync'd tabs) but I suspect few encounter the bug. Marking as an access-s2 because this is completely broken for keyboard users. This might be on the border of s3 but I could not find a workaround so leaving at access-s2 for now. The same bug occurs on the list in the account menu.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 2•3 years ago
|
||
Any update on this, One year already yet no one assigned, *sad noises
Does this need any C or Rust knowledge to implement fix? I wanna try, but I don't know where to start
Comment 3•3 years ago
|
||
The severity field for this bug is set to S3. However, the accessibility severity is higher, [access-s2].
:jaws, could you consider increasing the severity?
For more information, please visit auto_nag documentation.
Comment 4•3 years ago
|
||
(In reply to Benyamin Limanto from comment #2)
Any update on this, One year already yet no one assigned, *sad noises
Does this need any C or Rust knowledge to implement fix? I wanna try, but I don't know where to start
It should be just JavaScript and DOM knowledge needed to fix this. The code for the event listener is here, https://searchfox.org/mozilla-central/rev/1c54648c082efdeb08cf6a5e3a8187e83f7549b9/browser/base/content/browser-sync.js#322-326
Would you like to work on it?
Comment 5•3 years ago
|
||
(In reply to (Away 4/14 to 4/21) Jared Wein [:jaws] (please needinfo? me) from comment #4)
(In reply to Benyamin Limanto from comment #2)
Any update on this, One year already yet no one assigned, *sad noises
Does this need any C or Rust knowledge to implement fix? I wanna try, but I don't know where to start
It should be just JavaScript and DOM knowledge needed to fix this. The code for the event listener is here, https://searchfox.org/mozilla-central/rev/1c54648c082efdeb08cf6a5e3a8187e83f7549b9/browser/base/content/browser-sync.js#322-326
Would you like to work on it?
I will try to look into it first, and try to built the Firefox from Source
Updated•2 years ago
|
Assignee | ||
Comment 6•2 years ago
|
||
I can't seem to reproduce this on macOS. The menu item functions as expected, and the menu doesn't close.
Comment 7•2 years ago
|
||
This bug does not reproduce for me on Windows either, I'm seeing the expected behavior. We may have let this one sit for so long that another change just happened to fix it. :(
Assignee | ||
Comment 8•2 years ago
|
||
Thanks so much for checking this on Windows, Molly! I can also confirm it's not reproducible in Nightly on Ubuntu, so I'm going to close this out.
Assignee | ||
Updated•2 years ago
|
Updated•1 years ago
|
Description
•