User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

1. In about:config set keyword.enabled to false.
2. Enter in the address bar "test:" (without doublequotes).

Actual results:

The information in the address bar was being sent to a search provider (in my case Google).

Expected results:

No information should have been sent to a third-party in this case.

Additional information:

I figured this out today by accident that some characters ending on the first colon cause the information in the address bar being sent to Google causing a potential unintentional privacy impact. Eventually this string is just some form of a specific keyword that triggers the search? But on the other hand keyword.enabled should, well, disable keyword searches. It also appears there is no other option to workaround this privacy issue.

Note we don't send anything to search engines automatically, unless search suggestions are enabled.
In this case, the string is sent to the search engine only when confirmed (with enter or by picking a result).

It looks wrong anyway, thus it's a valid bug and concern. When keyword.enabled is set, any inserted string should just try a visit, even if the string it a totally invalid url.

It would be nice to know if this is a regression, I'll set the fields until we get a regression range.
If you want to help figuring it out you can use mozregression to find the first Firefox build where this started happening and findind which bug caused it, that would speed up a fix.

Hi, we tried to reproduce this issue on our end on a Windows 10 but after setting keyword.enabled to FALSE and search for "test" we just get a Connection Timed out. We can't reproduce this issue in Fx Release 70.0, Beta 71.0b3 or our latest Nightly build 72.0a1 (2019-10-24).

Are we missing any other preferences ? settings ? extensions ?
@sworddragon2 does this issue occur with a fresh profile as well ?
You can find the steps here on how to do that : https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

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

Note we don't send anything to search engines automatically, unless search suggestions are enabled.
In this case, the string is sent to the search engine only when confirmed (with enter or by picking a result).

My main profile where this issue appears has even search suggestions disabled in about:preferences#search. Also I did minimize the URLbar-results as much as possible (with a minimum of showing only what I enter preffixed/suffixed with some strings (like http://)) as my previous approach to hide it fully has high maintenance costs[1]. This is also the reason that I noticed this issue since when I enter "test:" the only entry in the URLbar-results suggests me a search with Google against my entered string.

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

If you want to help figuring it out you can use mozregression to find the first Firefox build where this started happening and findind which bug caused it, that would speed up a fix.

Unfortunately as busy as I am this is very unlikely to happen so I'm mainly here to report this bug and get it evaluated (valid, invalid, etc.).

(In reply to Rares Doghi from comment #2)

@sworddragon2 does this issue occur with a fresh profile as well ?

Even with a complete new profile on Windows 10 Professional 64 bit (version 1903) with Firefox 70 and only setting keyword.enabled to false I'm able to reproduce this issue (even after a restart of Firefox to make sure keyword.enabled got applied correctly; after entering "test:" into the address bar and pressing enter I get forwarded to https://www.google.com/search?client=firefox-b-d&q=test%3A exposing the content I typed in the address bar to Google).

(In reply to Rares Doghi from comment #2)

Are we missing any other preferences ? settings ? extensions ?

Your post implies that you did enter "test" in the address bar and thus missing the ending colon. Try to reproduce this issue with "test:" again.

[1]Unfortunately there is no way anymore to hide the whole URLbar-results without the use of the userChrome.css (where just hiding the URLbar-results did already break the third time this year for me so I did give up this approach). But once you disable as much as possible and it shows you effectively only what address you type without suggestions (with the only exception being this current bug) I see no reason to not auto-hide the URLbar-results - not even an additional option is required.

Yes, the colon after test is important, I can also reproduce with "test:"

Hello Again, Thanks for the extra info it seems the "test:" did the trick, I tried to do a mozregression and it seems this issue goes back to Fx62, I couldn't get an accurate range since there was not enough data to bisect but hopefully this helps:

Last Known Good build:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a382f8feaba41f1cb1cee718f8815cd672c10f3c&tochange=380cf87c1ee3966dd94499942b73085754dc4824

First Known Bad build:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=87cc179438941649616131ed9bb0c6f0766c8028&tochange=380cf87c1ee3966dd94499942b73085754dc4824

The only relevant thing there seems to be bug 1239708, maybe it's not a direct regression, but it made the bug visible? IIRC there we started stripping protocols, whatever they were, while before we were stripping only ftp, http, https.

Too late for a fix in 70 for this regression from 62. We could still take a patch for 72 and potentially 71.

Marking as fix-optional for 71, Marco if you have a patch in 72 and think it's worth uplifting it to beta, don't hesitate, thanks.

Bug 1489853 is a duplicate?

It's possible they have the same root cause, but the bugs as written talk about different things, so I think it's worth keeping them both open. I'll mark the other one as a see-also, thanks.

Let's just dupe to bug 1489853, they point to the same regressing bug and test: currently is working.