• [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

Jamie, looks like panel keyboard navigation code might be interfering here, like in bug 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.

(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.)

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?

(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.

https://hg.mozilla.org/mozilla-central/rev/e18f5b9d4cc4

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?

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.