User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

I type in the search top field (address field) text like "owl.carousel", "intervention/image", "phpunit/phpunit" and so on.

Actual results:

Instead of opening Google search it's trying to load not existing domains like: "http://www.owl.carousel/", "http://intervention.com/image", "http://www.phpunit.com/phpunit" and so on.

Chrome browser opens google search for all this requests.

Expected results:

It should open google search with typed strings like Chrome browser does. It actually worked properly before the latest upgrade, now it's very annoying as I often copy paste things like "intervention/image" and expect it to open google search page and not something like "http://intervention.com/image".

Thanks for reporting this. I tested on 65.0.2, 66.0.5, 67.0.4, and 68.0.1. On all those versions, owl.carousel resulted in Firefox trying to visit http://www.owl.carousel/. Do you remember which version of Firefox you were using before, where owl.carousel resulted in a search?

On 68, I do see that intervention/image and phpunit/phpunit result in visits to http://intervention.com/image and http://www.phpunit.com/phpunit. On the earlier versions, they result in searches.

Until we fix this, you can force a search by putting your text in double quotes, like "intervention/image" (including the quotes).

I'll mark this as a regression because I don't think we intended on changing the behavior re: intervention/image.

Marking regressed-by as quantumbar-release until we find a specific bug.

I think this is just bug 1080682.
There is no way currently to tell whether "owl.carousel", "intervention/image", "phpunit/phpunit" are valid urls without that, I think Chrome just checks against the list of valid tlds to make a choice, we don't have that list yet (but it's being worked on)

My previous comment is actually only valid for "owl.carousel", for intervention and phpunit, we should probably consider them search strings because they aren't in browser.fixup.domainwhitelist.*
The current code thinks those looks like urls, but we should distinguish based on the host part of the url.

Thanks, I knew we had a bug that covered owl.carousel. The other two cases in comment 0 though are quantumbar regressions somehow, and what we should probably focus this bug on.

I think the problem can be solved in the tokenizer, and while there we may look into bug 1551049

Since it touches the tokenizer, I was wondering whether bug 1560228 would be related, too.

maybe not strictly related, we'll still have to tokenize the restriction char, we just have to add it back later.

Yeah this doesn't seem to be related after all, removing the see-also.

I think bug 1398567 and bug 1080682 pretty much cover the needs here, so I'm just resolving this one as a duplicate of the meta bug