1412985 - Entering email address in the awsomebar forces site login attempt rather than search for email address

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[Don Holeman]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171024165158

Steps to reproduce:

My browser has Search Shield Study 3.0.6 extension installed which apparently is a test of a unified address and search bar. Using the combined bar I want to search the web for a particular email address, for example my own - [e-mail].


Actual results:

I get a dialog box with this message:

"You are about to log in to the site “cox.net” with the username “dholeman1”, but the website does not require authentication. This may be an attempt to trick you.

Is “cox.net” the site you want to visit"


Expected results:

It should have pulled up my default search engine with the results of a search for my email address. 

I think this bug may actually be a feature and, if so, presents a design dilemma for the combined search bar as to which function to perform, log into a website or search for the email address.

Comment 1

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

it is a design dilemma indeed, the problem is that the string looks both like a url and an email. Though, we can probably distinguish the email case and do the right thing.

Comment 3

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Attachment: Bug 1412985 - The address bar shouldn't try to convert an email address into an url. r=adw

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.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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.

Comment 6

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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.

Comment 7

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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?

Comment 8

[Drew Willcoxon :adw]

(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 [e-mail], 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.

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(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).

Comment 10

[Drew Willcoxon :adw]

Sounds good.

Comment 11

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Attachment: Bug 1412985 - Add a forced search urlbar result for e-mail like strings. r=adw

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/36ef44f48eb4
Add a forced search urlbar result for e-mail like strings. r=adw

Comment 13

[Razvan Maries]

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

Comment 14

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

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

Comment 15

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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.

Comment 16

[Pablo]

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