Closed Bug 309582 Opened 19 years ago Closed 12 years ago

freeze/hang while typing nonexistent address in location bar when using proxy

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 769764

People

(Reporter: janneo, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

When typing nonexistent address to location bar Firefox 1.0.7 freezes. This
happened also with version 1.0.6.

Reproducible: Always

Steps to Reproduce:
1.When typing nonexistent address to location bar Firefox 1.0.7 freezes
2.
3.

Actual Results:  
Firefox freezes.

Expected Results:  
"page not found" or something like that.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050922
Firefox/1.6a1 ID:2005092205

WFM. Does it also happen in the safe mode?
http://kb.mozillazine.org/Safe_Mode_(Firefox)
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
Gecko/20050915 Firefox/1.0.7
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
Gecko/20050915 Firefox/1.0.7
> 
> When typing nonexistent address to location bar Firefox 1.0.7 freezes. This
> happened also with version 1.0.6.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1.When typing nonexistent address to location bar Firefox 1.0.7 freezes
> 2.
> 3.
> 
> Actual Results:  
> Firefox freezes.
> 
> Expected Results:  
> "page not found" or something like that.

This also happens in safe mode.
Same bug for me :

Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2

I'm currently behind a SQUID proxy, but I have the same freezes at home with direct connection.
Tested in both safe and normal modes.

The freezes last for 20-40 seconds, and then FF continue to work as expected.
Reporter, do you still see this problem with Firefox 2.0? If not, can you please close this bug as WORKSFORME. Thanks!
Whiteboard: CLOSEME
Hello! Yes, the same issue occurs with version 2.0.0.4. My friends also have this problem so it's not related with one client. 
Janne, what version of firefox are you currently using? (You can do Help > About and copy and paste the user agent string here (starts with 'mozilla').
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Thanks. Are you also behind a proxy like the person in comment 3?
Version: unspecified → 2.0 Branch
Whiteboard: CLOSEME
Yes, I am. If I use "Direct connection to the Internet" option it seems to be working without these annoying freezees. I have to try this at home. I cannot access the Internet here if I use no proxy. Interesting...
Whiteboard: CLOSEME
It works just fine without proxy!
Summary: freeze while typing nonexistent address to location bar → freeze/hang while typing nonexistent address in location bar when using proxy
Whiteboard: CLOSEME
I can acknowledge this bug!

- I'm using an automatic-proxy-configuration script (wpad.dat) file. Whenever I enter a non-existent hostname firefox freezes for round about 30-40 seconds.

- If I've entered a static proxy within the configuration fields or disable the proxy use, this bug/freeze does NOT appear for me.

So this freeze ONLY appears using the automatic proxy-configuration possibility.

This bug/behaviour is reproducible every time I try it.

I'm using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Seems that there are a lot of people having this kind of problem:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=proxy+freeze
I have one more hint:

If I enter within the url-bar:

www.google.domain <- this does not freeze firefox
www.google.d <- firefox freezes

Don't know exactly why it freezes at the 2nd version but not at the first.
I'm also using automatic proxy configuration script.
Another hint could be that I'm using Windows. A colleague tested it with Ubuntu Linux and no freeze appeared.

So I think that this phenomenon only appears with Windows OS.
Nothing new?

What else do we have to report to get this status "confirmed"? This is a really bad matter which makes it difficult for companies to use firefox in combination with an automatic proxy-configuration.
Please test with a trunk build:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

If the problem still happens there, i'll punt this bug over to Core:Networking, but I'm hesitant to set this to NEW since I have no way of reproducing the problem myself.
Perhaps you can repoduce it like is:
Add this file to your as your "automatic proxy configuration url":

http://www.realriot.de/files/test/proxytest.pac

No surf to sites like:

http://www.google.e
http://this.sucks.co

With this "short" testfile the freeze isn't as long as with a more complex and long file... perhaps dns problems? timeouts?
I've tested it with the latest trunk. There's the same behaviour as with version 2 of firefox...
So could this either be a direct dupe of bug 235853, or a dupe of one of the dependancies off of bug 79893?
I really found a workaround for this problem:

Use your wpad.pac file like this:

function FindProxyForURL(url, host)
{
   if (isResolvable(host)
   {
       <... your stuff ...>
   } else
      return "DIRECT";
}

This works for me... 

Greets
Sascha
> So I think that this phenomenon only appears with Windows OS.

Unfortunately it does not, I'm running Linux and I've been experiencing freezes due to automatic proxy settings (even with existent adresses) in the location bar for 2 years now.
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Version: 2.0 Branch → unspecified
I'm getting freezes from proxy access on Camino on OSX:

I get continual hangs even if I'm not doing anything. I assumed that this was
caused by Camino 1.6, but I backed out to Camino 1.5.5 and I'm still getting
it... so I went in with Activity Monitor and found this was always due to a
bunch of nested js_Invoke called by nsPACMan::getProxyForURI, called, at the
top level, from -[Bookmark refreshIcon]

Sample trace from Activity Monitor attached to Bug 235853
As far as I remember using FF on my corporate networks, I allways had a freeze when the host url does not exist.

Today, discovering that this problem was reported, I did the test.

My current version is Firefox/3.0.1 (Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1)

The corporate proxy is squid/2.5.STABLE14

Test 1: using autoproxy
- type an url in the adress bar to a non-existant host (e.g: http://surcouf.fr )
- press enter to load the page ==> freeze for a while 

Test 2: using manual setting for proxy
- type an url in the adress bar to a non-existant host (e.g: http://surcouf.fr )
- press enter to load the page ==> no freeze
I can confirm this bug as per comment 25
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11

My corporate pac file is something like this:

function FindProxyForURL(url, host)
{
	if (shExpMatch(url, "http://127.0.0.1/*"))
		return "DIRECT";
	if (shExpMatch(url, "http://127.0.0.1:4664/*"))
		return "DIRECT";
	if (isPlainHostName(host)) 
           	 return "DIRECT";

      if (isInNet(myIpAddress(), "10.0.62.0", "255.255.255.0"))
                        return "PROXY 10.0.62.1:3128";
else
		return "DIRECT";	
}
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hum, I did a test today with my new version of Firefox (Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1), it seems there are no more freeze. But the proxy is different than when I reported on comment #25. Now it is Astaro.
As per comment 27 I've re-tested the above testcase with Firefox 3.5.1 and I cannot reproduce.

The corporate proxy is squid/2.5.STABLE14.
Depends on: 235853, 208287
No longer depends on: 208287
No further comments/changes made since the middle of 2009, though the bug still occurs.

Is there anybody who feels able to fix this bug?
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.