Closed Bug 1042157 Opened 10 years ago Closed 10 years ago
Cant find local servers when Home Page is set
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 (Beta/Release) Build ID: 20140722030201 Steps to reproduce: Im using Firefox Nightly 34.0a1. I set the Home Page (in Options > General > Startup) to an URL (e.g.: google.com). Then I navigate. Actual results: Nightly can access perfectly remote servers (e.g.: mozilla.org) but shows a "Server not found" error message for local servers (located in my own machine [localhost] and other machines in the LAN [192.168.1.X] using both HTTP and HTTPS). If then I set the Home Page to empty an restart Nightly I can access local servers perfectly again. Using wireshark it seems that Nightly does not throw a request. Expected results: Home Page configuration should not affect the way Nightly accesses local or remote servers.
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 (Beta/Release) Build ID: 20140722030201 This bug happens to me after I open any website. Accessing a local server works if I just open a new tab without anything in it, but if I go to a webpage first (like www.google.com) then trying to access the web server running on localhost:8000 takes me to www.localhost.com:8000.
Are you using a proxy?
I use a local proxy (port 8080) as a cache for some favorite website's & forums' buttons & images, since a couple of days after a couple of minutes of browsing using the local proxy, I get nothing more than either "Unable to connect" and "Unable to find the proxy server" messages. These also appear so spontaneous that I suspect not even an attempt is made to request anything via the proxy (in my case, localhost:8080)
Yes, I am using a proxy (I'm on the network at my workplace).
Looks like a dupe of bug 1041511, then.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Im not using a proxy nor firewalls nor user script nor any kind of add-ons which could be interfering with Nightly navigation. Indeed when I use a proxy (OWASP ZAP Proxy for testing requests for this bug) it seems to work perfectly but if I set no proxy it fails again. Also I have tested it in different environments (different machines, different networks, different OS) even in a fresh install of Nightly. To reproduce the bug please go to Nightly Options > General > Startup and set your Home Page to an URL (e.g.: google.com) and restart Nightly to confirm that the new config is active and then try to access a web server in your LAN (e.g.: the web interface of your home router 192.168.1.1 (or the proper IP in your case)) or in localhost and you should get a "Server not found" message. Using the Dev Tools Network Profiler you can see that Nightly even tries to connect to the remote server as the connection just takes 0ms. Also using wireshark you can confirm this as you wont see an HTTP request. Additionally Im also experiencing the www.localhost.com problems mentioned above, but I thinks thats a different bug.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
[Tracking Requested - why for this release]: [Tracking Requested - why for this release]: [Tracking Requested - why for this release]: Regression window(m-i) Good: https://hg.mozilla.org/integration/mozilla-inbound/rev/c57608929ef7 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140718104420 Bad: https://hg.mozilla.org/integration/mozilla-inbound/rev/b786f0b2d1bd Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140718105317 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c57608929ef7&tochange=b786f0b2d1bd regressed by: b786f0b2d1bd Steve Workman — Bug 354493 - Add nsINetworkZonePolicy to protect resources loaded from private IPs r=mcmanus
Status: UNCONFIRMED → NEW
Component: Location Bar → Security
Ever confirmed: true
Product: Firefox → Core
Version: 34 Branch → 33 Branch
Can you try if the builds from http://email@example.com/try-win32/ (which include the patch for bug 1041511) fix this issue for you? I would expect them to, looking at the patch...
(In reply to :Gijs Kruitbosch (Gone July 26 - August 3) from comment #8) > Can you try if the builds from > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/sworkman@mozilla. > com-8e3a63e3afd7/try-win32/ (which include the patch for bug 1041511) fix > this issue for you? I would expect them to, looking at the patch... The try build fixes the problem.
Yes, the proposed build fix the bug.
Then I think this is the same issue still.
You need to log in before you can comment on or make changes to this bug.