1221560 - http://localhost/ on a machine with no webserver shows a blank page instead of a network error

Status: RESOLVED INVALID

(Firefox :: Address Bar, defect)

Description

[Camelia Badau [:cbadau], Desktop Test Engineering]

Attachment: issue.png

Reproducible on Firefox 43 beta 1 (BuildID: 20151103023037)
Mozilla/5.0 (Windows NT 6.1; rv:43.0) Gecko/20100101 Firefox/43.0

Steps to reproduce:
1. Launch Firefox.
2. Access about:config and set browser.fixup.domainwhitelist.localhost to FALSE.
3. Type "//localhost" in the Location Bar -without the quotes- and press [ENTER].

Expected results: Under Windows, the user is redirected to a server error page.

Actual results: A blank page is displayed. Please see attachment "issue.png". 

Notes: 
1. I saw this result (blank page) with browser.fixup.domainwhitelist.localhost set to TRUE. Even if the pref is true or false, the same result is displayed (a blank page). 
2. This issue is reproducible also on Windows 8 64bit. 
3. This issue is reproducible also on Firefox 38.0.5, on Firefox 40.0.2 and on Firefox 42 RC Build 2.

Comment 1

[:Gijs (he/him)]

I can't reproduce. I get redirected to the error page fine.

Besides, the domainwhitelist isn't relevant when there are two preceding forward slashes, so the pref setting doesn't serve a purpose, as far as I can tell.

Is this on a clean profile? Does it happen on linux as well? What about mac, with the builtin web server disabled?

Comment 2

[Camelia Badau [:cbadau], Desktop Test Engineering]

Yes, it's on a clean profile. 

I've tested:
- on Ubuntu 13.10 32bit - typing "//localhost" on the Location Bar redirects on a "File not found" page (which is expected on Ubuntu)
- on Mac OS X 10.9.5 (using sudo apachectl start and sudo apachectl stop to disable the web server) - typing "//localhost" on the Location Bar redirects on a "File not found" page (which is expected on Mac).

According to bug 1047600 comment #1, this issue is Windows-specific.

Comment 3

[:Gijs (he/him)]

43 is beta now - does this reproduce on 44 and 45, with/without e10s? Are you sure there is no webserver running on the machine you're testing? What does view source (ctrl-u) show when the blank page is up? What URL (in the title of the tab/window) and what content?

Comment 4

[Camelia Badau [:cbadau], Desktop Test Engineering]

There is no webserver running on the machines I've tested. As I said in Description, the issue is reproducible on Windows 7 32bit and on Windows 8 64bit, that means 2 different machines: machine A, with Windows 7 32bit and machine B, with Windows 8 64bit. 

I've tested also on another machine (Windows 10) and here, typing "//localhost" on the Location Bar redirects to a "Unable to connect" neterror page (even if the pref is true or false), not to a blank page. 

I've tested: 
- on latest Nightly 45.0a1 (buildID: 20151104030437) and the issue is reproducible with and without e10s like as in Description (a blank page is displayed)
- on latest Aurora 44.0a2 (buildID: 20151104004053) and the issue is reproducible with and without e10s  like as in Description (a blank page is displayed)

Please see in the attachment what view source show when the blank page is up.

Comment 5

[Camelia Badau [:cbadau], Desktop Test Engineering]

Attachment: view-source.png

Comment 6

[:Gijs (he/him)]

On the machines where this is broken, what happens if you type:

http://localhost/

 ?

Comment 7

[Camelia Badau [:cbadau], Desktop Test Engineering]

Attachment: attachment1.png

I have the following results: 
- when pref is true, typing hhtp://localhost/ on the Location Bar redirects to a blank page. See attachment1 [details] [diff] [review].  
- when pref is false, typing http://localhost/ on the Loacation Bar redirects also to a blank page. See attachment2 [details] [diff] [review].

Comment 8

[Camelia Badau [:cbadau], Desktop Test Engineering]

Attachment: attachment2.png

Comment 9

[:Gijs (he/him)]

Are there errors in the location bar when this happens? What page was loaded in the tab before you did this?

Comment 10

[:Gijs (he/him)]

(if the full URL has the same problem this clearly has nothing to do with the location bar's leading slash redirection or otherwise)

Comment 11

[Camelia Badau [:cbadau], Desktop Test Engineering]

In the Location Bar aren't errors. I've opened "http://localhost/" always on a new tab page. 

Here is what I have in the Browser Console when this happens: 

" GET http://localhost/      [HTTP/1.0 404 Not Found 10ms]

The character encoding of the plain text document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the file needs to be declared in the transfer protocol or file needs to use a byte order mark as an encoding signature.                                                    localhost "

Comment 12

[:Gijs (he/him)]

(In reply to Camelia Badau, QA [:cbadau] from comment #11)
> In the Location Bar aren't errors. I've opened "http://localhost/" always on
> a new tab page. 
> 
> Here is what I have in the Browser Console when this happens: 
> 
> " GET http://localhost/      [HTTP/1.0 404 Not Found 10ms]
> 
> The character encoding of the plain text document was not declared. The
> document will render with garbled text in some browser configurations if the
> document contains characters from outside the US-ASCII range. The character
> encoding of the file needs to be declared in the transfer protocol or file
> needs to use a byte order mark as an encoding signature.                    
> localhost "

Errr, so clearly those machines have *something* that returns a 404 instead of just not accepting the connection or whatever. You should find out what it is (maybe there's a proxy configuration that's influencing the results?). Just using telnet to talk to port 80 on that machine might help figure out what it is, as would checking with the network pane in the web toolbox whether the responses for the http://localhost/ request indicate what is generating the response.

In any case, that means this report is invalid.