I had a look into why this is happening.

The menu is an OOUI MenuSelectWidget. Pressing tab chooses the option, just as clicking does. Here's the code for that:

OO.ui.MenuSelectWidget.prototype.onDocumentKeyDown = function ( e ) {
    ...
    switch ( e.keyCode ) {
        case OO.ui.Keys.TAB:
            if ( currentItem ) {
            // Was only highlighted, now let's select it. No-op if already selected.
            this.chooseItem( currentItem );
    ...

See also: https://gerrit.wikimedia.org/g/oojs/ui/+/4d43a2c5fe6caa28d36c21be437c4081c50e2157/src/widgets/MenuSelectWidget.js#156

Special:Investigate then handles the choose event according to the option - navigating to another page, refreshing the same page with different parameters, etc.

In other words, it's decided upstream that tab and click both select an option, but we're doing something unusual downstream by having the options do things, rather than just get selected.

@Prtksxna Do you think this behaviour needs changing (and if so, how should it behave instead)?

In T261862#8087340, @Tchanders wrote:

@Prtksxna Do you think this behaviour needs changing (and if so, how should it behave instead)?

Would it be possible for us to change the behavior just for Special:Investigate, or would it need to be upstream too?

I was looking at the select/options HTML tag on different browsers (using this as the demo), on MacOS Safari and Chrome don't do anything on ⇥ (tab) but Firefox selects the currently focussed option. Can't find any specific direction on what tab should do in the Aria documentation either (not exactly the same element, but similar).

Would it be possible for us to change the behavior just for Special:Investigate, or would it need to be upstream too?

I'd expect we can change it just for Special:Investigate, unless we encounter something unexpected

In that case let us change the behavior to:

1. Not select anything in the menu that is open

… I have two thoughts about what it should do :

2a. Cycle through the options in the menu
OR
2b. Go to whatever is next in the tabindex for the triple dot menu

What do you think?

@Prtksxna I find this the most intuitive:

2b. Go to whatever is next in the tabindex for the triple dot menu

If you're happy with that, I'll get to work on it. Thanks!

Sounds good to go ahead with 2b.

Change 821779 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/extensions/CheckUser@master] Fix keyboard UI in Special:Investigate results table

https://gerrit.wikimedia.org/r/821779

Change 821779 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Fix keyboard UI in Special:Investigate results table

https://gerrit.wikimedia.org/r/821779

@Tchanders I cannot get the menu to work properly with a mouse. I can open the menu but clicking any of the options does not do anything. I have tested on Firefox and Chromium. Could you check this?

I don't know how much we should expect the HTML to be the same before and after.

I see an extra, hidden <div> element:

  <div class="oo-ui-widget oo-ui-widget-enabled oo-ui-selectWidget oo-ui-selectWidget-unpressed oo-ui-clippableElement-clippable oo-ui-floatableElement-floatable oo-ui-menuSelectWidget oo-ui-element-hidden" role="listbox" aria-multiselectable="false" id="ooui-5">
  </div>
  <div class="oo-ui-widget oo-ui-widget-enabled oo-ui-selectWidget oo-ui-selectWidget-unpressed oo-ui-clippableElement-clippable oo-ui-floatableElement-floatable oo-ui-menuSelectWidget" role="listbox" aria-multiselectable="false" style="top: 32px; right: 0px; width: auto; max-width: 1045px; max-height: 383px;">
...

Change 822634 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/extensions/CheckUser@master] Override onDocumentMouseUp handler in InvestigateMenuSelectWidget

https://gerrit.wikimedia.org/r/822634

Change 822634 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Override onDocumentMouseUp handler in InvestigateMenuSelectWidget

https://gerrit.wikimedia.org/r/822634

In T261862#8147674, @dom_walden wrote:

I don't know how much we should expect the HTML to be the same before and after.

I see an extra, hidden <div> element:

  <div class="oo-ui-widget oo-ui-widget-enabled oo-ui-selectWidget oo-ui-selectWidget-unpressed oo-ui-clippableElement-clippable oo-ui-floatableElement-floatable oo-ui-menuSelectWidget oo-ui-element-hidden" role="listbox" aria-multiselectable="false" id="ooui-5">
  </div>
  <div class="oo-ui-widget oo-ui-widget-enabled oo-ui-selectWidget oo-ui-selectWidget-unpressed oo-ui-clippableElement-clippable oo-ui-floatableElement-floatable oo-ui-menuSelectWidget" role="listbox" aria-multiselectable="false" style="top: 32px; right: 0px; width: auto; max-width: 1045px; max-height: 383px;">
...

Oh yes, this isn't ideal indeed! It's because we add two menus - OOUI's default one and our custom one. However, when I remove the default one, it stops working for a reason that wasn't obvious from a bit of debugging... Rather than spending more time pursuing that, I think we should make a less fragile fix, which would be to allow the OOUI widget to accept a custom menu as a config. Filed as T315240: Allow custom menu to be passed in to OO.ui.ButtonMenuSelectWidget and T315241: Remove InvestigateButtonMenuSelectWidget

Tab now closes the tools menu, but keeps the focus on the ...

Otherwise, I did not notice any other differences in behaviour when using it with keyboard or mouse.

I was only able to test on Firefox and Chromium. I will wait until this is deployed to testwiki (~1800UTC tonight) to test on Safari (which I will probably do tomorrow morning). I will keep it in the QA column until then.

Test environment: Local docker CheckUser 2.5 (90ed3ee) 13:50, 15 August 2022.
Test browsers:

• Firefox 91, 103.
• Chromium 87, 102.

In T261862#8154500, @Tchanders wrote:

...Rather than spending more time pursuing that, I think we should make a less fragile fix, which would be to allot the OOUI widget to accept a custom menu as a config. Filed as T315240: Allow custom menu to be passed in to OO.ui.ButtonMenuSelectWidget and T315241: Remove InvestigateButtonMenuSelectWidget

Great. I will do more testing on those.

In T261862#8156150, @dom_walden wrote:

I was only able to test on Firefox and Chromium. I will wait until this is deployed to testwiki (~1800UTC tonight) to test on Safari (which I will probably do tomorrow morning). I will keep it in the QA column until then.

I have just done testing on testwiki on Safari 14 and 15. I could use the tools menus with both keyboard and mouse. Tab dismissed the menu.