1780404 - The unable to connect page is not displayed when DNS points to a valid but inexistent address

Status: NEW

(Firefox :: Address Bar, defect, P5)

Description

[Cristian Baica [:cbaica], Release Desktop QA]

Found in

• Fx104.0a1

Affected versions

• Fx104.0a1

Affected platforms

• Windows 10

Preconditions
Have a keyword set in your OS hosts file like:
::1 cognizantsoftvision

Steps to reproduce

1. Launch Firefox.
2. Set browser.fixup.dns_first_for_single_words to true.
3. Open a new tab and type in cognizantsoftvision and hit enter.

Expected result

• Error page is displayed.

Actual result

• A search is performed.

Regression range

• This is not a regression.

Additional notes

• Please see the discussion in bug 1778655#c3, the last paragraph for more details and context.
• Upon further discussion this might be something related to the localhost redirect, but warants more investigation as the expected result is not reached (the error page).

Comment 1

[Marco Bonardo [:mak] (Away 10-21 August)]

Yeah this is something to investigate, or at least figure out the code path we take in this case.
It's possible the current behavior is wanted, but we must describe it better through code first, because there may be historical reasons for it.

Comment 2

[Cristian Baica [:cbaica], Release Desktop QA]

Further investigation turned out that this occurs only on Windows. So the issue seems more likely to be a routing through localhost than we first thought.

Comment 3

[Cristian Baica [:cbaica], Release Desktop QA]

(In reply to Cristian Baica [:cbaica], Release Desktop QA from comment #0)

Expected result

• Error page is displayed.

In comment 3 James is mentioning the 'Unable to connect' page is expected. We were wondering in what other places or other scenarios can this page be encountered.

Comment 4

[James Teow [:jteow]]

I'm a little confused by the question.

The Unable to Connect page should only be expected in our specific case because we're "mocking" the existence of a single word that maps to an IP address for the purpose of testing that the preference works. By searching that word and landing on an "Unable to Connect" page instead of a search page, we've confirmed that the browser has found an IP address associated with the single word but wasn't able to connect to a server because I'm presuming on your machine you don't have something running at the address you provided for that keyword.

We could for example start a server on localhost (e.g. via Node.js), map a single word like cognizantsoftvision to the same IP as localhost (like you've done in your hosts file), so that typing cognizantsoftvision would go to the page served by the server listening on localhost instead of showing an "Unable to Connect" page, but the outcome for our purposes would be the same, namely proving that the preference works. If you'd like, I can set up a Github repo with a super basic Node server setup, so that you would download the repo, run it locally on localhost, and provided you map the address correctly in your hosts file, should expect to see the result from the Node server instead of a search result.

If you are just generally curious about what circumstances "Unable to Connect" shows up, we can needsinfo someone on the networking team (e.g. Kershaw) to give more clarification.

Comment 5

[Adrian Florinescu [:aflorinescu]]

(In reply to James Teow [:jteow] from comment #4)

I'm a little confused by the question.

If you are just generally curious about what circumstances "Unable to Connect" shows up, we can needsinfo someone on the networking team (e.g. Kershaw) to give more clarification.

Apologies, we didn't mean for the question to be confusing:: during a brainstorming today we figured that for this specific issue, we should be expecting "Unable to connect" page for the exact reasons you explain in the above comment, but in the same time we realized that aside from this issue particular scenario, we are clueless in which other scenarios we would ever show this page and not the server error one.

Comment 6

[James Teow [:jteow]]

Gotcha, thanks for the clarification Adrian.

:kershaw, you helped me with a networking bug a few months ago so I feel like you might be more equipped to answer this question. We're just wondering what are some scenarios should we expect to see the "Unable to Connect" error state of the aboutNetError page?

The title of the page seems to be set based on connectionFailure error. Based on the checks in docShell, it looks like this error is set when a connection was refused (e.g. a service that should be listening on the port has crashed or otherwise unavailable?) or the error was 502 Bad Gateway Error ("a server acting as a proxy/gateway received an invalid response from the upstream server" - MDN). Could the existence and behaviour of a firewall (e.g. refusing access to a server) also cause this error?

One specific scenario we observe is if the browser attempts to a navigate to a host that has an IP address in a clients hosts file and the server at that address isn't responding, the browser will show this "Unable to Connect" page.

Comment 7

[Kershaw Chang [:kershaw]]

(In reply to James Teow [:jteow] from comment #6)

Gotcha, thanks for the clarification Adrian.

:kershaw, you helped me with a networking bug a few months ago so I feel like you might be more equipped to answer this question. We're just wondering what are some scenarios should we expect to see the "Unable to Connect" error state of the aboutNetError page?

I think the answer is whether the address bar interprets the input as an URL and tries to navigate to it.
In this case, the address bar think cognizantsoftvision is not an invalid URL (not sure why this only happens on windows), so we show the search result.
In other cases, the input can be interpreted as an URL, we try to start the document loading process. A docShell that is used to load this document is created and the logic that shows the error page is here.

Comment 8

[James Teow [:jteow]]

Thanks Kershaw.

Adrian and Cristian, just digging into the code a bit, it would seem the connectionFailure state of the page gets shown when the error is either NS_ERROR_PROXY_BAD_GATEWAY (502) or NS_ERROR_CONNECTION_REFUSED (503). Mappings of the errors to codes

502 Error - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/502 - The proxy server is working but the upstream server it's trying to access gives an invalid response for a variety of reasons (it could be down, a firewall could be blocking the proxy server from accessing the upstream server)

503 Error - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503 - The server could be overloaded or under maintenance.

Comment 9

[Marco Bonardo [:mak] (Away 10-21 August)]

The problem is likely not much about the error type, but more about why on Windows ::1 is interpreted differently than on other platforms.

The urlbar is not involved here, when browser.fixup.dns_first_for_single_words is set to true, the urlbar just passes down the raw string to the loader. The documentloadlistener then tries to load it and on certain errors, fallbacks to fixup that may change the url to a search.
I think that's at https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentLoadListener.cpp#2318-2409

I suspect we're taking a different code path when resolving ::1, but not in the urlbar.

I don't think this is a super critical problem anyway, unless we discover it happens with other addresses and more common use-cases.