1512643 - Manage keyboard navigation through groups of results

Status: RESOLVED INCOMPLETE

(Firefox :: Address Bar, enhancement, P3)

Description

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

There are a few unknowns about keyword navigation in the new View.
One thing is about side navigation, we could have one row having multiple results side by side.
For example a Top Sites row may just contain rich icons of top sites, layed out horizontally.
Another example may be providing local matches grouped on the left, and content discovery matches on the right.

How would the user move to those side matches? The more tatually solution would be RIGHT/LEFT, but since the input field is always on focus, how do we distinguish between moving the cursor or moving to a side match?

Comment 1

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I'm thinking we could, for accessibility reasons, actually implement bug 1437524. Once we'll have a mixed horizontal/vertical navigation and side by side grouped matches, we'll need a way to switch betwween groups, tab sounds like a perfect fit for that.

Comment 2

[Drew Willcoxon :adw]

The thought occurred to me that we kind of have a use case for this right now, and we have for a while: the one-off buttons. We treat them as being separate from the main part of the view, and so they're a special case. But we could instead think of them as being integrated into the results of the stock/default view, and if we did think of them that way, how would we implement them and their interactions? Even if we never do implement them that way, it might be useful to think about. That line of thinking also aligns with the fact (imo) that there's no reason to assume the one-offs would generally make sense in other view implementations/UXes.

Comment 3

[Dão Gottwald [:dao]]

(In reply to Drew Willcoxon :adw from comment #2)

The thought occurred to me that we kind of have a use case for this right now, and we have for a while: the one-off buttons. We treat them as being separate from the main part of the view, and so they're a special case. But we could instead think of them as being integrated into the results of the stock/default view, and if we did think of them that way, how would we implement them and their interactions? Even if we never do implement them that way, [...]

I think it would make sense to do so. The reason why this isn't done that way at the moment is that the quantumbar shares the one-off search button code with the awesomebar and the search bar.

Comment 4

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Summing up a little bit, a plan may be:

1. TAB cycles through groups (results, one-offs, hilights...). This requires a selectNextGroup() API
2. UP/DOWN navigates to the next item in a transparent way, once a group is done it moves to the next group, if there is only one group it moves to the top of it, the order of groups is decided by the view
3. LEFT/RIGHT is no more supported in the view, it just acts on the input field
4. one-off buttons should work as one of these groups. We may need a compat layer for the search bar.

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

There's no short term plan for groups, and TAB was kept as navigation through results, thus keeping this open is not particularly useful.