1754546 - Firefox treats host/path as a search query instead of an http(s) request

Status: RESOLVED DUPLICATE of bug 1642435

(Firefox :: Address Bar, defect)

Description

[es.rosenberg+github]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

Setup a host in the search domain of your computer/network

Try to browse to host/path instead of explicitly typing the FQDN/path

Actual results:

A search for host/path is run

Expected results:

The browser should have opened http(s)://host/path

Tested on Firefox 96/97 on Ubuntu (21.10/22.04) and macOS (12.2)

It should be noted that browsing to host/ does work but the moment any path is added (and there is no longer a trailing slash) it stops working, going to host/path/ (with a trailing /) also works, but host/index.html will run a search.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Szymon Scholz]

Windows 10, UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

Reproduced

Comment 3

[es.rosenberg+github]

This bug seems to be similar to:
https://bugzilla.mozilla.org/show_bug.cgi?id=1644463

And though it offers many workarounds I do think that the essential behavior is wrong and non standard (even though it seems most browsers have strayed onto this non standard path, so a discussion can be had to as to what is a standard when the whole world ignores it).

Maybe the logic should be modified to something along the lines of (pseudocode):

if input.contains(/) {
if(check_if_substring_before_slash_resolves()) {
open_url(input)
} else {
search(input)
}

The current logic also breaks down in a different case:

• open a new tab and put a string that starts with / in the "big search bar" (ie express the wish to search for this string and not browse to it)

It will be treated as a path and not a search unless entered into the classic search field (yes I still have an address bar and a search field, but my address bar behaves as the mishmash that everyone gets).

The above case should definitely be treated as a path when entered into the address bar/super bar, but when entered into the "search bar" displayed centrally on the new tab page it should absolutely be treated as a search since that is an explicit statement of user intent to search.

Comment 4

[Simona Badau, Desktop QA]

I could not set up a host due to some restrictions on my environment. Marco, when time allows, could you please take a look over this issue?
Thanks!

Comment 5

[Drew Willcoxon :adw]

Thanks for filing this, but we have very similar bugs on file already that cover this, bug 1642435 in particular. Please see the discussion there for workarounds and reasoning.

Comment 6

[es.rosenberg+github]

Should I open bugs about the other wrong behavior that I mentioned? (entering a path in a search field causes a uri_open() instead of a search)

Comment 7

[es.rosenberg+github]

Also where in the source can I find this logic I would be happy to have a look and submit a PR instead of just filing a bug.

Comment 8

[Drew Willcoxon :adw]

When you type in the search field on the new tab page, the address bar switches to search mode using your current engine. When I type "/foo", my address bar enters Google search mode, and when I press enter, I get a Google search for "/foo". Does it not do that for you?

Comment 9

[es.rosenberg+github]

This may be because I'm on Linux/macOS and paths start with a /.

When I type /foo either in the address bar or in the new tab search bar it gets converted to file:///foo only if I use the dedicated search bar will it run a search for /foo.