1851722 - Addressbar entry with "[e-mail]" should be a search

Status: NEW

(Firefox :: Address Bar, task, P3)

Description

[Daniel Veditz [:dveditz]]

+++ This bug was initially created as a clone of Bug #1842324 +++

Gecko supports the ancient (and controversial) "userinfo@" part of a standard URL's authority section, but HTTP Auth is so rarely used that if the user enters it manually in the address bar without a scheme we should assume it's a search rather than trying to construct a URL out of it. We do give users an obscure warning about phishing if they do this, but it's such an obscure feature that people don't even know what that means. I consistently see URLs in this format described as "unwanted redirects" by bug-bounty hunters, and if they don't know any better an average netizen has no chance.

We used to have a heuristic that if the addressbar had a space then it was a search, but this foils that. For example, consider a hypothetical search for someone's email address: An addressbar "search" for "John Doe @gmail.com" is turned into http://[e-mail]/

Comment 1

[Marco Bonardo [:mak]]

We actually detect this case and provide a "Search" second result when it happens.
We have some ideas to build "alternate/secondary" actions for results, and this may also fit there, so by default search for the string, but provide an alternative sub button to visit. TBD.

Ignoring the userinfo part is of course another possibility we could look into.
I'm not sure how common those are or whether that will break users expectations. It would be nice to check how other browsers are handling the case, just to avoid surprising users when they move to Firefox, or when they use multiple browsers.

Overall I agree with your sentiment, thus I think with some brief analysis we could proceed with it.

(In reply to Daniel Veditz [:dveditz] from comment #0)

We used to have a heuristic that if the addressbar had a space then it was a search, but this foils that. For example, consider a hypothetical search for someone's email address: An addressbar "search" for "John Doe @gmail.com" is turned into http://[e-mail]/

This is a bug, I think it's also filed elsewhere (must search for that bug). Spaces in userinfo should be encoded IIRC, though this works and that's what causes the bug on our side new URL("http://John Doe @gmail.com"). Pretty much we trust the URL parser.
Another things we could do is checking the validity of the domain suffix through the PSL.
Though these would not be super critical to fix, if we take the "always search" approach. They would be nice to have for the alternate action path.