From https://phabricator.services.mozilla.com/D161776:

Focusing the button and pressing SPACE should open the menu, instead it puts a space in the input field

Hey, for the address bar result menu that is now enabled in nightly (e.g. for history results), I need help verifying that we can wontfix this bug. Can someone from the a11y team please weigh in? Here's what I had already discussed with mak:

[dao] mak: I think we should probably wontfix https://bugzilla.mozilla.org/show_bug.cgi?id=1801389, as it would interfere with typing spaces in the address bar. no other button in the view currently activates when pressing space. wdyt?
[mak] My concern is that every other button in the toolbar opens pressing space, so the user may expect it to work. I understand your concern that if we support it for the menu, we may have to support it for the other buttons too (for example quickactions), and then your space would be pretty much trapped if the result only offers buttons. That'd be bad.
Maybe we should ask accessibility what's their expectation? But of course even if they tell us it's 100% wanted, we could only have it on the result menus, not on the other buttons...
If a11y is fine and used to Enter, 100% ok to wontfix

I'm not familiar with this new menu. Can you please provide steps to reproduce?

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

I'm not familiar with this new menu. Can you please provide steps to reproduce?

In a recent Nightly build, type something in the address bar to search your history. Each history result (as opposed to bookmark results, for instance) will have an adjacent menu button that can be reached with the Tab key.

Got it. Thanks.

So the big difference with these menu buttons (vs results and other buttons in the address bar) is that these buttons are only reachable via tab. That makes sense, but it also makes them different and thus arguably sets different expectations. If I tab to a button, I initially expect that space is going to work. In contrast, if I'm up/down arrowing through an autocomplete list, I'm more likely to press enter (because it "feels" like a list).

What makes this particularly messy is the fact that tab also moves through autocomplete results as per bug 1437524. I'm guessing this is the main reason we're concerned about space not typing into the address bar; i.e. if a user presses tab twice, decides they don't want the result and then presses space?

Actually, I'm not quite following why a user would ever press space to type into the address bar while one of these menu buttons is focused. Doesn't the user have to explicitly tab to get to such a button? And if they do, that changes and selects all text in the address bar anyway, so pressing space will just insert a space at the start of the address bar text, which doesn't seem like a useful thing to do.

At this point, I'm inclined to argue that these menu buttons are different and that space should activate them. However, I'm sure I'm missing some scenario where this would actually be a problem, so I'd be keen to learn more about such a scenario.

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

So the big difference with these menu buttons (vs results and other buttons in the address bar) is that these buttons are only reachable via tab. That makes sense, but it also makes them different and thus arguably sets different expectations. If I tab to a button, I initially expect that space is going to work. In contrast, if I'm up/down arrowing through an autocomplete list, I'm more likely to press enter (because it "feels" like a list).

For context, the up/down arrow behavior was changed in bug 1801298.

What makes this particularly messy is the fact that tab also moves through autocomplete results as per bug 1437524. I'm guessing this is the main reason we're concerned about space not typing into the address bar; i.e. if a user presses tab twice, decides they don't want the result and then presses space?

Yeah. Do you think we should reconsider bug 1437524?

Actually, I'm not quite following why a user would ever press space to type into the address bar while one of these menu buttons is focused. Doesn't the user have to explicitly tab to get to such a button?

Yep.

And if they do, that changes and selects all text in the address bar anyway, so pressing space will just insert a space at the start of the address bar text, which doesn't seem like a useful thing to do.

Selecting the button actually clears the input right away, but anyway, yes, space would only get you that single space as the input value at that point.

At this point, I'm inclined to argue that these menu buttons are different and that space should activate them. However, I'm sure I'm missing some scenario where this would actually be a problem, so I'd be keen to learn more about such a scenario.

Alright, let me take a stab at implementing this.

(In reply to Dão Gottwald [::dao] from comment #5)

What makes this particularly messy is the fact that tab also moves through autocomplete results as per bug 1437524.

Yeah. Do you think we should reconsider bug 1437524?

Just a side note, both Edge and Chrome atm have tab moving through buttons AND rows. That's not to say we can't do better of course, just a matter of facts. Also space can be used to click on all the buttons, though they don't have pre-selected buttons like we do on certain results, so all of their buttons must be tabbed to.

(In reply to Dão Gottwald [::dao] from comment #5)

For context, the up/down arrow behavior was changed in bug 1801298.

One problem with this is that screen reader users have no idea that there are even additional buttons reachable with tab. They use the up and down arrows (because that's standard for an autocomplete), but there's no way for them to know that other buttons even exist. This is why I originally preferred that the up/down arrow keys reached those buttons. I can see why this was jarring (per bug 1801298) and it also involves a lot of extra key presses. To make matters worse, tab doesn't always take you to a menu button, only if the result has one. Honestly, I don't think there's a good way to "fix" this, but we might need to at least add something to our keyboard shortcuts documentation so users have a chance of discovering this.

Do you think we should reconsider bug 1437524?

I've argued that tab shouldn't move through autocomplete results for a long time now, but I also know there are users who are very attached to tab moving through autocomplete results, so it's hard to know whether changing it is really worth the user backlash.

https://hg.mozilla.org/mozilla-central/rev/06679a025cf7

Confirming this issue as verified fixed on 112.0a1(20230223094032) and 111.0b4(20230221190142) using Windows 11, macOS 13 and Ubuntu22.