Closed Bug 1561581 Opened 1 year ago Closed 1 year ago

[macOS] Unable to select another autoplay option from the drop down using the keyboard arrows

Categories

(Firefox :: Site Identity, defect, P3)

Unspecified
macOS
defect

Tracking

()

RESOLVED FIXED
Firefox 71
Tracking Status
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- fixed

People

(Reporter: Gabi, Assigned: Gijs)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

  • [Affected versions]:
    Nightly 69.0a1

  • [Affected platforms]:
    MacOS 10.14
    MacOS 10.13

[Steps to reproduce]:

  1. Go to cnn.com/videos
  2. Open the Site Information panel
  3. Select the Autoplay dropdown by clicking on it
  4. Using the keyboard up/down arrows try to select another autoplay option
  • [Expected]:
    User should be able to select another autoplay option from the drop down using the keyboard arrows

  • [Actual Results]:
    The focus is not changed to the autoplay options, the allow/block state can't be changed using keyboard only navigation

[Note]: Autoplay options can be changed with the keyboard up/down arrows if the focus to autoplay dropdown is made with the Tab key

Blocks: 1557002
No longer depends on: 1557002

Jamie, looks like panel keyboard navigation code might be interfering here, like in bug 1547635. :-(

Flags: needinfo?(jteh)
See Also: → 1547635

Strange. menulists should be excluded from arrow key navigation, regardless of whether they were focused by the key nav code or not:
https://searchfox.org/mozilla-central/rev/11712bd3ce7454923e5931fa92eaf9c01ef35a0a/browser/components/customizableui/PanelMultiView.jsm#1633
We have a test for just this functionality:
https://searchfox.org/mozilla-central/rev/11712bd3ce7454923e5931fa92eaf9c01ef35a0a/browser/components/customizableui/test/browser_PanelMultiView_keyboard.js#209
I can't reproduce this on Windows. I don't have a Mac to test with.
Also, if this were a similar situation to bug 1547635, I'd expect that down arrow should focus the next control, rather than just doing nothing.

Flags: needinfo?(jteh)

(In reply to James Teh [:Jamie] from comment #2)

Strange. menulists should be excluded from arrow key navigation, regardless of whether they were focused by the key nav code or not:
https://searchfox.org/mozilla-central/rev/11712bd3ce7454923e5931fa92eaf9c01ef35a0a/browser/components/customizableui/PanelMultiView.jsm#1633
We have a test for just this functionality:
https://searchfox.org/mozilla-central/rev/11712bd3ce7454923e5931fa92eaf9c01ef35a0a/browser/components/customizableui/test/browser_PanelMultiView_keyboard.js#209
I can't reproduce this on Windows. I don't have a Mac to test with.
Also, if this were a similar situation to bug 1547635, I'd expect that down arrow should focus the next control, rather than just doing nothing.

It looks like clicking a menulist to open it on mac doesn't focus it, so focus in the code right above your link is the <window> node, so we set it to null because it's not inside the panel, so tabOnly returns false, and we focus the first/last node in the panel.

Neil, what's the right way to detect this case, and/or is it even correct for the menulist not to take focus? (This is with "all controls" being focusable at the macOS level, so I would have expected menulists to be focusable and thus gain focus when clicked.)

Flags: needinfo?(enndeakin)

Neil, what's the right way to detect this case, and/or is it even correct for the menulist not to take focus? (This is with "all controls" being focusable at the macOS level, so I would have expected menulists to be focusable and thus gain focus when clicked.)

On Mac, menulists do not receive focus when clicked.

Keyboard handling for menus is done with capturing listeners on the document. They call stopPropagation and preventDefault if the key is handled.

Are you trying to handle the keyboard events before this?

Flags: needinfo?(enndeakin)

(In reply to Neil Deakin from comment #4)

Neil, what's the right way to detect this case, and/or is it even correct for the menulist not to take focus? (This is with "all controls" being focusable at the macOS level, so I would have expected menulists to be focusable and thus gain focus when clicked.)

On Mac, menulists do not receive focus when clicked.

Keyboard handling for menus is done with capturing listeners on the document. They call stopPropagation and preventDefault if the key is handled.

Are you trying to handle the keyboard events before this?

Yes, see discussion in bug 1536521.

Looks like moving the listener to the document's root element and checking for event.defaultPrevented is enough here.

Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Attachment #9090401 - Attachment description: Bug 1561581 - listen for key events in panels 'later' than the builtin menu handling code, r?NeilDeakin → Bug 1561581 - listen for key events in panels 'later' than the builtin menu handling code, r?jaws
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/e18f5b9d4cc4
listen for key events in panels 'later' than the builtin menu handling code, r=jaws
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 71

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Should we uplift this to 70?

Flags: needinfo?(gijskruitbosch+bugs)

I think the steps here are pretty niche (combination of mouse + keyboard usage), plus it only affects mac, and I'm worried there are other unforeseen consequences of where we put this listener so I'd rather let it ride with 71.

Flags: needinfo?(gijskruitbosch+bugs)
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.