Address bar intranet subdomains searched instead of opened
Categories
(Firefox :: Address Bar, defect)
Tracking
()
People
(Reporter: hlava.vit, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0
Steps to reproduce:
Type my intranet subdomain app.env.company.loc into address bar without http:// in front (have separate address and search bars) instead of opening it as it did in FF76 now it searches google instead. Did not find mention of this channge in whats new.
And cant find a way of dissabling this behavior, other than one by one whitelisting them, which is not feasable with hunderds of them.
Actual results:
Searched google instead of opening subdomain
Expected results:
Open webapplication on intranet.
|
||
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Comment 2•4 years ago
|
||
Firefox 78 resolves some of the problems with specific domain suffixes like: .local, .test, .example, .invalid, .localhost, .internal.
Rather than inventing new special suffixes it would be better to stick to one of the common ones.
If you are in an enteprise with a local DNS, you can set browser.fixup.dns_first_for_single_words = true in about:config (or autoconfig, or a policy), so Firefox will always go through the DNS before resolving to a search.
If you don't have a local DNS, you can whitelist a specific domain creating a boolean prefs in about:config (or autoconfig):
browser.fixup.domainwhitelist.MYDOMAIN
From Firefox 78 on, you can also whitelist a complete suffix (anything.MYSUFFIX):
browser.fixup.domainwhitelistsuffix.MYSUFFIX
Finally, from Firefox 78 on, you can enforce a visit by appending a slash at the end of the url, like mydomain.loc/
|
||
Comment 3•3 years ago
|
||
This does not only apply to "enterprise users with a local DNS [server?]" but also to everybody else who runs a (development) web server on their local machine or another device in the home network. What's the problem setting this to true as default?
|
|
||
Comment 4•3 years ago
|
||
(In reply to Yves Goergen from comment #3)
What's the problem setting this to true as default?
The problem is dns lookups can take time, and our common users don't want to wait before a page starts loading. They'd start using another browser that "feels" faster. We must provide a default experience that satisfies vast majority of users.
Or could it be set by the gui layout?
if only adress field is visible (adress field serves as search field as well) then behave as it does right now by default
if adress and search fields are separate, try to dns resolve anything written into adress field first. if it fails then try searching.
|
|
||
Comment 6•3 years ago
|
||
I understand that speed matters. I could think of two solutions for that:
- Only try to look up DNS if the entered string looks like a valid URI. Something like "host/path" or even "host/path/file.html" is valid, others like "weather today" not.
- Do the DNS lookup anyway but don't wait for it. Often I don't care as much that my default search engine will learn about the URI I entered. But it's not so easy to try and fix it by entering all those complex other characters to make the URI explicit (http://), especially when you're not used to do that anywhere else and you're in a hurry. So when the DNS lookup succeeds (usually it will do so quickly) a message could be displayed and let me navigate to that URI with a single click (didn't happen, but IIRC there was such a thing in the past). Of couse that host name once learned should be remembered and never searched again (for valid URIs). Because there's two things I don't like: Slow browsers and dumb browsers.
|
|
||
Comment 7•3 years ago
|
||
(In reply to Yves Goergen from comment #6)
- Only try to look up DNS if the entered string looks like a valid URI. Something like "host/path" or even "host/path/file.html" is valid, others like "weather today" not.
It's not so trivial, is a string like seti@home a url? is 123/a a url? what about day/month?
There will always be mistakes, and since the algorithm deciding what to do is only in the source code, users would have a hard time discerning what to expect. Having a common and understandable behavior simplifies both maintenance and users expectations.
We search unless the host is known or you request otherwise, it's simple as that.
- Do the DNS lookup anyway but don't wait for it. Often I don't care as much that my default search engine will learn about the URI I entered.
That's what we do, we search immediately but in the meanwhile we do a dns lookup, if that lookup is succesful we show a "did you mean to go to site?" notification bar. The problem is that this happens only for single words like "somehost" but not for "somehost/somepath". I think it may be worth filing a bug about that specific support, if you care about that (we could transform this bug, but less noise in tickets is always better).
There's some discussion on how to make the algo smarter in Bug 1642623. That bug also shows there's a counter example, some users NEVER want to disclose what they typed to the DNS server.
As I said, this is trivial on paper, a bit more complex when considering millions of users with different needs.
Description
•