From bug 1610718 comment 16:

We were specifically concerned about inundating the user with too many tab-to-search results. We're only supposed to show a tab-to-search result if the engine domain is autofilled. It would be annoying if we showed a Google tab-to-search result every time "g" was typed, but that appears to be almost what we're doing. I can reproduce in a different scenario: when an autofilled site starts with "g", we show a tab-to-search result for Google Drive. Weirdly, if I disable my Google Drive engine, neither Google nor Google Maps (which I have installed as an OpenSearch engine!) shows a tab-to-search result. It's not clear what's broken here.

I ran mozregression and the Wikipedia issue was sort of reproducible on the 2020-10-01 build when tab-to-search was introduced. A key difference being that we didn't yet show a Wikipedia tab-to-search result when "wikipedia.org" was autofilled, because the engine was actually for <locale>.wikipedia.org. I could reproduce the issue after installing an OpenSearch engine that pointed directly to wikipedia.org.

Something weird is happening with the muxer here.

The logic in the muxer seems fine. However, we let a result bypass it all if it has the attribute satisfiesAutofillThreshold. That's the attribute we introduced to allow near-matches, like showing an eBay tab-to-search result when the user is typing "ebay" even though the engine has the domain rover.ebay.com. Maybe we can improve the logic there.

satisfiesAutofillThreshold was indeed intended to bypass the logic for fuzzy matching, it sounds like I didn't consider much the case where we autofill a completely different domain.
The intent of the original patch was to allow tab-to-search for wikipedia without having to type "en.w", but just typing part of "wikipedia"... the logic then became to show tab-to-search if the typed string is included in the main part of the host "wikipedia.org" and that satisfies the threshold. In that case we don't care about autofill happening, and that's what satisfiesAutofillThreshold does.

The problem is that for "w" we may fill "www.google.com" and for "wi" we may fill "wiki.mozilla.org"... are we still supposed to show wikipedia tab-to-search in those cases? Probably not, so we should likely skip if we autofill a domain not "compatible" with the tts one.
The downside is we'll provide those tab-to-search entries less often, but likely we can't do much better.

This patch will reduce the number of TTS results we show, because we will no longer allow some partially matched hosts. Previously, we let some TTS results through the muxer even when a domain was not autofilled because we thought the user might be typing a subdomain of the TTS domain. However, this created false positives, as demonstrated in the bug. This patch strikes a compromise by retaining the satisfiesAutofillThreshold property, but requires the heuristic result to be a URL result. That way, we can ensure the TTS engine domain has the same hostname as the heuristic URL. This patch still handles the Wikipedia and eBay cases that satisfiesAutofillThreshold was designed to address.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=88269c64e5c8dec965542f63e921b8101bba60dc

Backed out changeset 2e289ebaa100 (bug 1713662) for Browser-chrome and XPCshell failures. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer?job_id=343397267&repo=autoland&lineNumber=2969

https://treeherder.mozilla.org/logviewer?job_id=343388605&repo=autoland&lineNumber=2390

Push with failures:
https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=2e289ebaa100e00d68e4d161e12239e7aa794a10

Backout:
https://hg.mozilla.org/integration/autoland/rev/3683ab8d97724fcc69cd7c9b407be5351b761f1d

https://hg.mozilla.org/mozilla-central/rev/c5ea8b8e40b9