Closed Bug 1676038 Opened 10 months ago Closed 10 months ago

frequently used subdomain shouldn't be autocomplete if full domain name entered

Categories

(Firefox :: Address Bar, defect, P2)

defect
Points:
3

Tracking

()

RESOLVED FIXED
85 Branch
Iteration:
84.2 - Nov 2 - Nov 15
Tracking Status
firefox-esr78 --- unaffected
firefox83 --- unaffected
firefox84 --- wontfix
firefox85 --- fixed

People

(Reporter: aryx, Assigned: mak)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Firefox 84.0a1

A frequently visited subdomain abc.example.org is the default action for pressing Enter ('Visit') label when I enter example.org. For a completely entered domain, the default action shouldn't be a subdomain

Steps to reproduce:

  1. https://developer.mozilla.org/ often (no idea how often is needed)
  2. Enter mozilla.org into the address bar.

Expected: mozilla.org should be in the first row with a 'Visit' label.
Actual: developer.mozilla.org as default action.

Workaround: Press Esc key.

Do you have a custom search engine going to developer.mozilla.org?
We started autofilling search engines this way, though this should only happen if mozilla.org would not be autofilled (so it's not a page you go to often or you bookmarked).

The case you are pointing out here is interesting and we should be figure out how to avoid replacing a fully typed domain with another one.

Severity: -- → S3
Flags: needinfo?(aryx.bugmail)
Keywords: regression
Priority: -- → P2
Regressed by: 1670253

I see 2 options here, either we autofill search engines only for singlewords (no dots), and we should still consider intranet domains, or we keep autofilling until the typed string has a valid public suffix, then we assume the user wants to visit that domain, not the suggested one. The latter is more expensive because we must lookup the suffix, the former may be more surprising because we'll autofill for "mozilla", but not for "mozilla." or "mozilla.o".
Drew, wdyt?

Flags: needinfo?(adw)

Yes, I have a search engine installed for the suggested subdomain (and a keyword assigned which is unrelated to the domain).

Flags: needinfo?(aryx.bugmail)

Based on the way it currently works, I can't think of another solution besides the ones you mention. I think your first solution would probably be sufficient. It would be easy to implement and would probably cover most cases IMO, and we could watch for user feedback and implement the second solution if necessary.

However, I'm just trying to reproduce this -- if I don't have mozilla.org in my history, then I can reproduce it. If I do have mozilla.org in my history and it passes the autofill threshold, then when I type mozilla, mozilla.org is autofilled and the heuristic is https://www.mozilla.org -- Visit, which is what you would normally expect. So we are only talking about the case where https://www.mozilla.org/ is not the autofill completed URL, right? And in that case, normally autofill would not kick in at all, and the heuristic would be mozilla -- Search with Google until you type a TLD, when the heuristic becomes a visit result, right?

The important desired UX here is to show the tab-to-search result for developer.mozilla.org as the second result. Can we simply keep the usual heuristics and autofill behavior while still including the tab-to-search? From a UX perspective, that seems like the desired outcome.

Flags: needinfo?(adw)

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

So we are only talking about the case where https://www.mozilla.org/ is not the autofill completed URL, right? And in that case, normally autofill would not kick in at all, and the heuristic would be mozilla -- Search with Google until you type a TLD, when the heuristic becomes a visit result, right?

Yes, it's the case mozilla.org would not be autofilled, the user types mozilla.org and instead of visiting mozilla.org we autofill developer.mozilla.org.

The important desired UX here is to show the tab-to-search result for developer.mozilla.org as the second result. Can we simply keep the usual heuristics and autofill behavior while still including the tab-to-search? From a UX perspective, that seems like the desired outcome.

Maybe, the problem is that the muxer throws away the tab-to-search results if the heuristic is not autofill. I could try moving the matching from the autofill provider to the tab to search provider, then add something to the result payload to tell the muxer to skip verification, something like an enforced result.

I think it may be feasible, let me look into that.

Assignee: nobody → mak
Iteration: --- → 84.2 - Nov 2 - Nov 15
Points: --- → 3

The previous approach was autofilling partial subdomains from search engines.
Having a search engine pointing to "developer.mozilla.org, when "moz" was typed
we ended up autofilling "moz[illa.org]" but pointing to "developer.mozilla.org".
Unfortunately that made impossible to actually go to "mozilla.org" by typing it.

The new approach instead allows tab-to-search results to appear even if there's
no autofill, because the provider checks autonomously the autofill threshold.
There's a downside though, with the old approach we could return more partial
matches, and the Muxer would pick one, depending on the autofilled host. For
example we could return "rover.ebay.com" and match it to "eb[ay.it]".
With the new approach we don't have an autofilled host, and fetching it would
be expensive, we can only compare the search string with the engine's host.
For this reason the patch also tries to partially match against the searchForm
host, that often points to a page the user visits more often.

Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/73e63ab5f476
Change partial tab-to-search matching to avoid autofilling unexpected subdomains. r=adw
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch

The patch landed in nightly and beta is affected.
:mak, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak)

I don't think it's worth the risk, it can only happen if the top level domain is not visited much, but the subdomain is, or the subdomain is bookmarked by the top domain is not, and the user types a part of the top level. I'd say that we'd better get more testing on the new approach to avoid replacing one problem with another one (So far so good, but better safe than sorry).
If we'll see more feedback or duplicates with more common use-cases, we'll re-evaluate.

Flags: needinfo?(mak)
You need to log in before you can comment on or make changes to this bug.