Evaluate supporting tab-to-complete for a partially-typed alias
Categories
(Firefox :: Address Bar, enhancement, P3)
Tracking
()
People
(Reporter: bugzilla, Unassigned)
References
Details
(Keywords: blocked-ux)
Attachments
(1 obsolete file)
This is so the user can use the muscle memory they will develop around tab-to-search with token aliases.
Updated•4 years ago
|
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Comment 1•3 years ago
|
||
Lowering priority since this is more relevant for tab-to-search, which will be done later.
Comment hidden (obsolete) |
Updated•3 years ago
|
Comment 3•3 years ago
|
||
It sounds like this would be good for ebay, where we'd never provide tab to search due to the "rover" situation.
Reporter | ||
Comment 5•3 years ago
|
||
Whether we want to show tab-to-show results for token aliases at all, and what that would look like. There are some edge cases here that might not look great visually. For example, if the token alias is being autofilled, do we show the autofill keywordoffer result as the heuristic and then a tab-to-search result for the same engine right underneath? Or should we just allow Tab/down arrow to complete token alias autofill?
Comment 6•3 years ago
|
||
I thought the purpose here was when the user types "e" to match on "@ebay", or "dd" on "@ddg" to provide the tab-to-search.
If the user is already typing an alias like "@e", it doesn't seem useful to provide a tab to search result, that's about discoverability and the user doesn't need it since they are already typing the alias.
Reporter | ||
Comment 7•3 years ago
|
||
Ah! That makes sense. Yeah, I think we could just go ahead with that without specification from UX.
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Comment 8•3 years ago
•
|
||
I spoke with Verdi about this. He is concerned that we'd show tab-to-search much too frequently with this behaviour enabled. In en-US, we have six installed keywords by default: @google
, @amazon
, @bing
, @ddg/@duckduckgo
, @ebay
, and @wikipedia
. If we implement this behaviour, we would show an extra result and an extra animation every time a user starts a search with g
, a
, b
, d
, e
, or w
.
I made the case that we want to support muscle memory that will develop around tab-to-search. We agreed that we would de-prioritize this bug and come back to it after tab-to-search has been in wide use for a bit.
I'll post the rough WIP patch I was working on for this.
Reporter | ||
Comment 9•3 years ago
|
||
Updated•3 years ago
|
Comment 10•3 years ago
•
|
||
Returning on my comment 6, I missed a use case and today I added an item to the UX agenda to discuss this behavior.
It could make sense to fill @tokens with Tab in the end, since we are introducing Tab to search, and this would be a case where the intent is clearly to search but tab doesn't complete.
Comment 11•3 years ago
|
||
So, this bug tracks partially typed aliases, while Bug 1669526 tracks partially typed token aliases (the ones starting with @).
It's likely Bug 1669526 will be fixed sooner, this one is still blocked-ux because there's concerns of autofilling too often.
Updated•3 years ago
|
Description
•