Impossible to teach autocomplete to select the root of some domains
Categories
(Firefox :: Address Bar, defect, P3)
Tracking
()
People
(Reporter: flod, Unassigned)
References
Details
After bug 1597791, it's impossible for me to have the address bar autocomplete github.com.
As far as I can see, the root domain is suggested only after I select it from a list of suggestions at least once. That was the case for Twitter or YouTube: start typing the domain, select it from the list of suggestions, and the address bar will learn to prioritize it.
That's impossible for GitHub, because github.com doesn't show up in the list of suggestions. All suggestions point to specific URLs (issues, repositories, etc.)
|
||
Comment 1•2 years ago
|
||
From some quick searching, this might be related to the heuristic behavior of showing "Visit" for bug 1523773 where the (special?) domain suggestion entry might not result in Firefox learning to suggest it in the future as it's added to the list differently?
Bug 1559686 seems to have inputhistory conditional on !heuristic?
|
||
Comment 2•2 years ago
|
||
The primary problem is that likely those suggestions should not have happened. That will be addressed in Bug 1769585.
The other problem is training the system, if we fill a url but you really want the base domain, you need some way to do that.
We could do a couple things:
- if you backspace a url autofill, reduce its score
- when presenting a url autofill, also present a result pointing to the base domain, that you can pick
Additionally one problem to think about is this:
Suppose you type "forum" and we have a signal that in the past you typed "foru" and picked "forum.guitars.com/products"...
we fill that, but you really want to go to the base domain. You use one of the above methods to train the system.
We'll add a signal for "forum" (what you actually typed) to go to forum.guitars.com, but the original "foru" signal will stay there. We may have to decay any signals shorter by one or 2 chars from the typed string.
|
||
Comment 3•2 years ago
|
||
The severity field is not set for this bug.
:adw, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 4•2 years ago
|
||
We've fixed bug 1769585 which should make this a little better but it's still possible for adaptive history autofill to override domain autofill, and we don't have concrete plans right now for a way to mitigate that. The only option is to remove the adaptive autofill URL from history or wait a max of 30 days for it to decay -- not great. Adaptive history autofill is currently disabled, so this bug is not currently reproducible by default, but it's a valid bug still.
|
|
||
Comment 5•2 years ago
•
|
||
ideally when it happens the user has recently typed the same string and picked exactly that url from the list.
There are a few options we could evaluate to address the problem:
- always add the bare domain result at a tab distance, so we provide an escape and a way to train the system. This means wasting a potential result but it could be a valid short term solution. Of course it should happen if we'd have autofilled the bare domain.
- allow to dismiss a suggestion as not good. Best long term though this requires a discoverable button/menu we don't have yet, it's planned for the future.
- Check if the url has a frecency over a certain threshold, the user may not be likely to want to visit a site that was visited rarely or just once... the problem is defining such threshold. Plus it's not given that a url is good for autofill regardless of how many times it was visited (indeed it would be nice to have a blocklist of domains that should not autofill urls).
|
|
||
Comment 6•2 years ago
|
||
For the frecency threshold (third option), we could also compare the full url frecency VS the base domain url frecency, and url autofill only if that url has an higher value than the base domain. This would solve quite a few cases, though we should also understand if it would exclude too many cases.
Example https://bugzilla.mozilla.org/show_bug.cgi?id=1769764 has much lower frecency than https://bugzilla.mozilla.org/
We could also add a pref to control the distance and make it more/less sensitive, cause one risk is that url autofill may not happen often enough if we just do a bare "less than" comparison.
|
|
||
Comment 7•2 years ago
|
||
The current nightly behavior has been working better for me since this bug was filed. E.g., these are my desired autocomplete that nightly correctly fills
"re" -> reddit.com/r/firefox/
"gi" -> github.com/
I think the tricky part is to even have an autocomplete entry to select. For example, I don't usually visit top level mozilla.org, and if I type out "mozilla.org" then all autocomplete entries are filled with "Switch to tab" except the first "Visit" entry, and just pressing enter (which is the same as selecting the first autocomplete entry ?) doesn't seem to help train that I want "mo" -> mozilla.org/ (as it currently wants to autocomplete to mozilla-hub.atlassian.net/).
I tried to trick/teach it by typing in a dummy mozilla.org/?autocomplete and typed out "mozilla autocomplete" and selecting the url to train inputhistory. And now typing "mo" autocompletes mozilla.org/?autocomplete 🤪
I think a related aspect is that mozilla.org actually redirects to mozilla.org/en-US/ so after realizing the "mozilla autocomplete" trick above, I typed in "mozilla internet for people, not profit" to also match on the title and filter out the "Switch to tab" and selecting that a few times to train inputhistory, I now get "mo" -> mozilla.org/en-US/
So I suppose it's possible to teach autocomplete but currently not naturally happening with normal/existing user behaviors.
Description
•