When the search string is not recognized by the tokenizer as a possible url or
origin, make search the default action, even if URIFixup may transform that
string into an url.
The transformed url is provided as a fallback visit result.
This is consistent with Chrome's behavior.
The urlbar, thanks to the bufferer, will always respect our choice, rather than
passing the value to URIFixup.
If keyword.enabled is false, never provide such search results.

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:mak, could you have a look please?
For more information, please visit auto_nag documentation.

This change was a little bit more complex than expected, because by inverting the behavior, we will trust the tokenizer before urifixup. There are 2 options here:

1. keep trusting urifixup, but blacklist some cases (like mail addresses)
2. trust the tokenizer

If we do 1) we may end up having to check multiple regex for the blacklist, if we do 2) we may have regressions until we port missing fixup rules in the tokenizer.

In the end, this is likely something to do in URIFixup itself. There are privacy implications to consider though, we tend to avoid sending things looking like uris to search engines, and here the boundary is very subtle.
I'm temporarily unassigning (not working immediately on this) and lowering the priority, to give us more time to consider the privacy implications.

If the use-cases for searching for an e-mail are not many, like I suspect, we should maybe take a different and less risky path, that is to provide an additional "search" result for this specific case, like we do for strings like "b.com". It would not be the default action, but it would still be at one DOWN of distance.

I'm tempted to do nothing here, and additionally undo bug 1256074.
For this specific case, I prefer to avoid handling mail addresses as visits by default, the privacy implications are problematic. So my solution would just be to add the forced search entry. BUT...

...when we implemented bug 1256074 we didn't have one-offs in release, nor the simple prepend/append ? workaround. We didn't have CTRL+K prepending the question mark. So it was effectively hard to force searching for a url-looking string.
Bug 1080682 (and the other fixes for bug 1180329) makes so the cases where we mishandle a search string as a visit are rare enough, for those rare cases the above features (one-off and question mark) should be sufficient. And we have a long term plan to allow put the urlbar in "search mode".

The forced search entry at this point is stealing precious space that could be better used by historical results and open tabs.
Drew, wdyt?

(In reply to Marco Bonardo [:mak] from comment #7)

For this specific case, I prefer to avoid handling mail addresses as visits by default, the privacy implications are problematic.

Just to be clear, this is what we do now, right? When I test on Nightly with foo@cox.net, Firefox navigates to cox.net. (And I don't see the message in comment 0.)

Could you explain the privacy implications? If foo is a real user at cox.net, then surely cox.net knows that, so what does Firefox reveal to cox.net when it connects with that username? Does it reveal something if foo is not a real user?

...when we implemented bug 1256074 we didn't have one-offs in release, nor the simple prepend/append ? workaround. We didn't have CTRL+K prepending the question mark. So it was effectively hard to force searching for a url-looking string.

That's a good point. ? isn't very discoverable even with the shortcut, but the one-offs are very visible, and with the planned search mode it really becomes easy. So I would be OK with closing this.

I do like the forced search result though. It's thoughtful and convenient and lets you know you can search for a domain too, if that's what you wanted. I have no idea how useful that is, maybe no one actually does that. We could make it behave like the private search result: Don't show it if there are also history or tab results.

Another option is that we could flip it for strings that look like email addresses: The heuristic result is search, and a forced visit result is below that, regardless of whether the domain suffix is known. So searching would be default and not visiting. I guess that would irritate the 12 people who log in to sites that way though.

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

(In reply to Marco Bonardo [:mak] from comment #7)
Could you explain the privacy implications? If foo is a real user at cox.net, then surely cox.net knows that, so what does Firefox reveal to cox.net when it connects with that username? Does it reveal something if foo is not a real user?

I'm sorry, I wrote visit when I meant search.
Doing a search by default is what I would like to avoid for privacy and security reasons.

So here we either:

1. do nothing
2. do nothing and also remove the forced search result (use one-offs, ctrl+k, future search button to search).
3. add a forced search result for emails
4. add a forced search result for emails and only show it when there are no/few history results

I was tempted to do 2) because bug 1080682 + one-offs made the feature obsolete.

I do like the forced search result though. It's thoughtful and convenient and lets you know you can search for a domain too, if that's what you wanted. I have no idea how useful that is, maybe no one actually does that. We could make it behave like the private search result: Don't show it if there are also history or tab results.

I also don't know how useful it's to search for a domain/email and why one-offs wouldn't suffice. But I notice that both Chrome and Edge provide the additional search result, so it is probably considered useful in general. They also provide it if there's history results.

So maybe for now the solution should be 3. and I should file a bug to investigate with UX whether this is more discoverable than one-offs (UR could be useful here).

Sounds good.

https://hg.mozilla.org/mozilla-central/rev/36ef44f48eb4

Can you please provide some STR for us to verify this issue?

type an email address in the urlbar, the first heuristic (preselected) result will be a visit, the second should always be a search for the email address.

verified on win10 64bit, macos 10.15, and ubuntu 18.04 with release 77, beta78b2 and nightly 79.