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.

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

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.

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