1566499 - After latest upgrade search / address bar started to navigate to not existing domains instead of opening google search

Status: RESOLVED DUPLICATE of bug 1180329

(Firefox :: Address Bar, defect, P3)

Description

[vedmant]

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".

Comment 1

[Drew Willcoxon :adw]

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.

Comment 2

[Drew Willcoxon :adw]

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

Comment 3

[Marco Bonardo [:mak]]

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)

Comment 4

[Marco Bonardo [:mak]]

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.

Comment 5

[Drew Willcoxon :adw]

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.

Comment 6

[Marco Bonardo [:mak]]

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

Comment 7

[Drew Willcoxon :adw]

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

Comment 8

[Marco Bonardo [:mak]]

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

Comment 9

[Drew Willcoxon :adw]

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

Comment 13

[Marco Bonardo [:mak]]

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