1886974 - The dropdown menu only expands or collapses after clicking "Builtin Roots Module" button multiple times

Status: NEW

(Firefox :: Settings UI, defect, P3)

Description

[fzxcvqwerasd]

Attachment: attachment

Affected Version:

• Firefox 123.0.1 (64-bit)

Affected Platforms:

• MacOS 14.1 (23B2073)
• MacOS 14.1.2 (23B92)

Steps to Reproduce:

1. Open about:preferences.
2. Enter "certificates" in the "Find in Settings" search box.
3. Click the "Security Devices…" button.
4. Click the arrow icon on "Builtin Roots Module" button to expand and collapse the dropdown menu
5. Click the other position on "Builtin Roots Module" button to expand and collapse the menu

Actual Results:

• At step 4: Clicking the arrow icon allows for expanding or collapsing the dropdown menu as intended.
• At Step 5: The dropdown menu only expands and collapses after clicking the other position on "Builtin Roots Module" button many times

Expected Results:

• Clicking any position can expand or collapse the context smoothly

Note:

• Other buttons with dropdown menu also have this issue

Comment 1

[Cieara Meador [:cmkm]]

A single click on the arrow in a tree item expands the item, but when clicking on the rest of the area, a double click is expected. Is it possible that your double click speed setting has been modified? You can check this setting by opening your macOS System Settings and searching 'double click', or if you're using an external third-party keyboard, you may need to check the settings in its corresponding application.

Comment 2

[Cieara Meador [:cmkm]]

Anna, is the need to double click to expand items possibly an accessibility concern with the XUL tree component? As far as I can remember, this is how these sorts of trees have always worked, but that doesn't necessarily mean it's the most accessible. Do you have any thoughts?

Comment 3

[Anna Yeddi [:ayeddi]]

(In reply to Cieara Meador [:cmkm] (she/her) from comment #2)

Anna, is the need to double click to expand items possibly an accessibility concern with the XUL tree component? As far as I can remember, this is how these sorts of trees have always worked, but that doesn't necessarily mean it's the most accessible. Do you have any thoughts?

Are we reusing the same XUL tree component as the Bookmarks sidebar (cmd/ctrl+B)? In there, a single click anywhere on the row of the parent node is expanding/collapsing the node.

That's being said, in the rich tree view (which the Security Devices… dialog appears to be using), a single click on the row opens that node in the main view vs Bookmarks sidebar does not have any main action assigned to the parent node. The Devices dialog has each parent nodes in the tree to work as a control to open this section in the view, thus we probably cannot overwrite that action (single click to activate the node's view) to opening/closing the node in the tree. Especially, because there is a specific control (the chevron) provided for each parent node row to perform that action. I am not aware of any W3C example that would be totally similar to the one that we have in the dialog, but this navigation tree view has the same dual behavior: single click activates the treeitem, chevron opens/closes the node.

Also, I tested the Security Devices dialog with keyboard on macOS (with the full keyboard access) and the arrow keys work on the tree elements as expected, opening/closing the nodes too.

I'm adding the access keyword so when we could triage it on the Disability API side of things to, if after the investigation into preventing the reporter from working with the tree we'd uncover anything that we could do for the a11y too.

Thank you for the reporting, :fzxcvqwerasd! And thank you for pinging me, :Cieara!

Comment 4

[Eitan Isaacson [:eeejay]]

This looks like a XUL issue, and isn't related to the disability API as far as I can see. I also don't think this is exclusively and access issue, and probably doesn't warrant the keyword.

Comment 5

[James Teh [:Jamie]]

Dropping access keyword since this appears to be in line with accessibility requirements/conventions as per comment 3.

Comment 6

[Ina Popescu, Desktop QA]

I've replicated this issue on the latest Firefox version 124.0.2 on macOS 13. Consequently, I am setting its status to NEW.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.