Closed Bug 1506952 Opened 5 years ago Closed 3 years ago

Use tab autocomplete for @ shortcuts


(Firefox :: Address Bar, enhancement, P3)






(Reporter: shorlander, Unassigned)


(Blocks 1 open bug, )


Something that feels missing here is the ability to use tab to quickly autocomplete a search shortcut. 

For example I frequently type @a and immediately want to hit tab to complete that to @amazon. Instead tab takes me to the first result.

Part of the reason that this feels so jarring is that typing @ looks like it will put you into a mode where that would work, but instead it doesn’t.

The other reason this feels off is that for many text based input methods tab autocomplete is the standard way to do this. I.e. Command Lines; Messaging apps: Slack, Telegram, WhatsApp, etc.; Email Addresses; Chrome’s off-site search; etc.

I think we should consider typing the @ symbol as a mode selector and if trying and type a matching shortcut (e.g. @am) we should use tab to autocomplete that instead if selecting the next result.
Priority: -- → P1
See bug 1437524, this is not a trivial decision because it will add complication to an already complicate matter.
Basically we'd want tab to move to one-offs for accessibility reasons, but we have a vocal minority using tab to move through results, and now we want to add another special behavior where tab completes a shortcut...
And note that I'd be all in favor of making tab complete the shortcut and if there's no shortcut go to one-offs. The problem is bug 1292321. If someone in product wants to take responsibility for this, we can move on, otherwise it sounds like we'll just hit the same wall.
Also, to put this into perspective, we actually added telemetry to study bug 1437524, and it looks like Nightly is the channel where tab is used more (makes sense, it's more technical users), though the amount of selections made through tab amounts to just 0,22%, while mouse and arrows are around 10%.
Yes, there is a lot of complexity in the awesome bar results panel.

Due to the intersection of adding more sections to the awesome bar results and the historical decision to make tab behave differently in this one list.

Using tab to autocomplete in this instance would seem to side step that complexity though, because we don’t show the one-off buttons if you start into @ complete mode.

But even if that were not the case, I am still not sure this conflicts with how tab ordering works, because as I mentioned about typing @ would indicate a mode switch.
Priority: P1 → P3
Drive by opinion: I also hit this when trying out the feature. In probably every application I've used where autocomplete is available, Tab is the key to do that. I actually thought there was something wrong with my keyboard when that didn't work :) Turns out Enter did do the autocomplete, but that non-intuitive, as in the awesome bar it also has the meaning of "I want to load what I just typed".
So, I support comment 4 in making tab autocomplete - if that's possible.
note though that tab would only autocomplete @shortcuts. it would not autofill other entries, and then I'm sure someone would find it inconsistent and ask for it to work on autofill. At that point we have a problem because we need a way to move through groups in the address bar panel (suppose we have multiple groups of results, plus one-off buttons that is a further group). Since autofill is quite common, tab would end up pretty much always autofilling, and we'd need another way to move through groups, that I'm not sure what may be, the current ALT+UP/DOWN is totally undiscoverable and horrible for accessibility.

I'm honestly not sure why we need TAB to complete autofill or shortcuts when RIGHT is clear enough and always available.
(In reply to Marco Bonardo [::mak] from comment #6)
> note though that tab would only autocomplete @shortcuts. it would not
> autofill other entries

That would be fine with me, and it would be consistent with Chrome's behaviour when typing 

> I'm honestly not sure why we need TAB to complete autofill or shortcuts when
> RIGHT is clear enough and always available.

I agree with you, but somehow typing @ makes me feel like tab should work. I think it's the way it looks. For regular URL autofil, when I type "you", going for, it's the rest of the string "" that is selected.
When I type "@ama" it's the ama that is selected, and zon not selected. I think the selection is what's guiding my expectations about what should or shouldn't work.
I see, thanks for clarifying.

I used this @search feature for the first time and I intuitively expected TAB to accept the already autocompleted keyword.

In the end this happened in bug 1669526, non @ keywords are tracked in bug 1647901

Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.