To show a tab-to-search result, we check if the user's search string prefixes an engine's result domain. For example, a search string of am would prefix amazon.com. We then check if the result domain is being autofilled. If it is, we show the result.

We have a few engines whose result domains don't match their homepage domains. The main examples are eBay and Wikipedia. eBay's result domain is rover.ebay.com, but a user would never have a reason to type rover.ebay.com so they will never see an eBay tab-to-search result. Similarly, Wikipedia's result domain is <locale code>.wikipedia.org, but most users would start typing wikipedia.org to autofill Wikipedia.

We should fix this so users can type the engine's homepage URL (e.g. ebay.com, wikipedia.org) and get a tab-to-search result for that engine.

I'm going to set this as a P2 so it gets picked up. Ideally, we resolve this in the general case. Special-casing eBay and Wikipedia would also be fine. In that case, we could bump this bug down to a P3 and spin off the eBay and Wikipedia special case into P2 that can get fixed in time for update2 landing in Release.

I don't think that currently we have any engine with a different resultDomain (we should but we don't have them).

For wikipedia I can't think of a simple solution, we don't autofill wikipedia in most cases when typing "w", thus we'd also not fill tab-to-search. I must note Chrome has the same bug, I have an engine for it.somedomain.com, it is autofilled only if I start typing "it", not if I start typing "some".
That's likely more a bug of autofill in general.

For ebay, we could change the matching in https://searchfox.org/mozilla-central/rev/4352fb7b0d17c1febff9569ed311e0e42c93093e/browser/components/urlbar/UrlbarSearchUtils.jsm#65-74, rather than checking that the engine host starts with our string, check if it ends with our string. Basically we'd only match the top level domain, ignoring subdomains.

Just briefly speaking with Standard8, it's clear that resultDomain is pretty much useless nowadays, it just always boils down to templateURI.host.
I think we should just remove it and figure out a better solution for the future. The original reason for that attribute is autofilling search engine domains, but that feature never made to release and is disabled.
Reverse parsing is using SearchStaticData, it's a different use case than autofill so it may not be the right solution for this bug.

For tab-to-search, I think we should analyze if my idea to match the end of the search url host with the autofilled origin (rather than the beginning) works for the built-in engines,. If we don't find problems with built-in engines, it should be fine.
Potentially, if that becomes problematic for some engine, we could add a bool to the engine definition like "autofillwithsubdomain" or such.

Based on discussion, here we should make the matching a lot more lenient to support Ebay at least, that likely means remove the public suffix from both origins, then check if the engine host ends with the autofill host. Though, we must verify this won't cause problems to the other built-in engines, otherwise we may have to special case just a few.

I'll file a separate bug for autofilling engines as a longer term fix.

moving the dependency of bug 1669477 to bug 1669529

It looks like we may also be comparing in a case sensitive matter since A[mazon.com] doesn't provide tab to search but a[mazon.com] does...

https://hg.mozilla.org/mozilla-central/rev/851a5d0db975

The issue is verified fixed using the latest Fx97.0a1 and Fx96.0b10 on Windows 10, Ubuntu 20.04 and macOS. The autocomplete is done for ebay.it (which was opened in several tabs) and if the search is done using tab-to-search, the engine used is the default ebay engine (in my case ebay.de).