Closed Bug 1566499 Opened 5 years ago Closed 4 years ago

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


(Firefox :: Address Bar, defect, P3)

68 Branch





(Reporter: vedmant, Assigned: mak)




(Keywords: regression)

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

Component: Untriaged → Address Bar

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

Ever confirmed: true
Keywords: regression
Priority: -- → P2

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

Regressed by: quantumbar-release

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

See Also: → 1551049
See Also: → 1412985

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

See Also: → 1560228

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.

See Also: 1560228
Assignee: nobody → mak77
Depends on: 1412985
See Also: 1412985
Iteration: --- → 70.3 - Aug 5 - 18
Points: --- → 2
Blocks: 1180329
Blocks: 1605983
No longer blocks: qb-results-papercuts
Points: 2 → 3
Iteration: 70.3 - Aug 5 - 18 → ---
Priority: P2 → P3

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

No longer blocks: 1180329
Closed: 4 years ago
Resolution: --- → DUPLICATE
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.