120.52 KB, application/octet-stream
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Firefox will hang if you accidentally type a single word (no dots) the in address bar/field and then hit 'Enter'. It hangs reliably. Try typing 'abc' and then hit enter. I notice this a lot because I sometimes forget the .com etc, or I accidentally enter my search word in the address field and not the google field. Very frustrating because when you have Windows kill Firefox it kills *all* instances of Firefox. This is very annoying. BTW, I am using Firefox from behind a Firewall and Proxy at work all day long. However I think it also happens when I am at home and hence not behind a firewall and proxy. Reproducible: Always Steps to Reproduce: 1. Type 'abc' in the address bar 2. Hit enter 3. Watch it hang Actual Results: I waited and waited and waited and eventually killed the browser from the Windows Task List which then unfortunately killed all opened Firefox browsers. Expected Results: 1. Not Hung, or 2. Allowed me to stop the request, or 3. Gone and search google for the word.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050227 Firefox/1.0+ We may need more information. Stack trace? HTTP log? WFM as per your scenario 3, I was taken to ABC.com
See Bug 283634 "Crash on Typing an address in location bar and hittin Enter in Firefox 1.0.1 PC" - that may be nothing to do with your problem & a red herring.
I have just tried it again - from home - and it did go to abc.com as you mentioned in your reply. Could it be that the proxy server at work, where I have the problem, is queried by Firefox getting some kind of reply that it doesn't like and then causes Firefox to hang (or wait a very very very very long time)? How would I trace what is happening when FireFox talks to the proxy server? Any help would be appreciated. BTW, I have checked Opera and IE, and they don't do hang like Firefox. Thanks, Evan.
I agree that it would be nice to know why it is that your proxy is not interoperating with Firefox. I have made some suggestions in Bug 278189 "Firefox randomly and frequently throws google home page and google error page while using proxy"
Reporter: Is this still a problem with the build from http://www.mozilla.org/projects/firefox/?
the Deer Park Alpha 1 build i mean :)
I have seen the behaviour mentioned in comment 3 when using a proxy (I thought that it was just one of those things, and didn;t stop to think about it); but I haven't yet tried with a recent version of Firefox.
Yes it is still a problem. It hangs for a long time when I put any address that cannot be resolved in the address bar. It does, eventually come back. In the meantime, every Firefox browser window that is running is hung. Also, you cannot open a new browser window. It only happens at work where I am behind a proxy. Microsoft IE and Opera do not do this. Or perhaps they do and time out sooner. Another idea: it may have something to do with the way Firefox uses google to try to resolve the URL. Thanks, Evan.
WFM on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050711 Firefox/1.0+ Looking up for 3 sec and went searching Google (in the status bar) then jumped to the result.
For me (also behind a proxy), it hangs for about five seconds before I get a Squid proxy page titled "The requested URL could not be retrieved", with comes back with a 503 error status "Service unavailable". Another weird related problem is every time I select that tab of the failed page then try to click on another good page, the browser hangs for about five seconds before showing the good page. Firefox used to try several DNS resolution queries if the request failed and blocked while it was doing so. I think now that problem is fixed, it's merely waiting for the proxy to respond (possibly to a DNS query, possibly to an HTTP request). Would love to get to the bottom of these sorts of problems so that a single word in the location bar performs a keyword search if it doesn't resolve to a host name. Possibly related to bug 252616.
I'd bet that it's related to proxy or name resolution problems. Your description suggests it's the same as bug 229668. Can you have a look and decide whether it is? (I don't think it is, since that was fixed a while ago, but just in case.) I think it's more likely that this is a problem that will be fixed with bug 2875 (which have better descriptions of symptoms in bug 269519 and bug 269577). If it's none of those, it will probably help if you post more details of your proxy settings (auto-detect/manual/auto URL/etc) and verify that your DNS name resolution is working correctly.
(In reply to comment #7) > I have seen the behaviour mentioned in comment 3 when using a proxy (I thought > that it was just one of those things, and didn;t stop to think about it); but > I haven't yet tried with a recent version of Firefox. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050812 Firefox/1.0+ It would be best to regard my comment 7 as a dup of Bug 2875 . I am afraid that I can't be sure whether the whole of this report is such a dup, there are 2 elements in it that I have not seen: The orignal hang comment 0 and comment 8 , and the delays in comment 10 .
Appears from comments to be a problem with the proxy server, not Firefox. Resolving INVALID.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
It happened again yesterday at work. I cannot get it to repeat at home. I suspect it is due to some interplay with the proxy. Due you know of any tools that I could use to sniff exactly what is being sent and received from firefox. I have looked at live http headers and the information is not enough. Again, to reiterate the bug I experience: I enter an URL in the address bar that doesn't exist. At home Firefox works fine by using Google to resolve a likely address. At work, however, Firefox completely locks up. I cannot even hit the "stop" button to stop the search. I can do absolutely nothing but wait more than a minute for it to return or kill the process. These days, I am trained like one of Pavlov dogs. I am in the habit, at work, of never entering an address I don't for sure know will be resolved. The downside of this is that I manually Google a lot more. Do you guys know of any tool / utilities that I can use to sniff out what is happening. Or perhaps, could the address resolution happen in another thread so that I could at least continue to interact with Firefox and hit the "stop" button. The reason it is such an inconvenient bug is that ALL Firefox windows lock up. BTW, I am a software developer and if you point me in the right direction, and if I can get a debug build that I can step into I might be able to pin-point the exact area in the code where it fails. Alternative, that area of the code could be redesigned to not lock up the Firefox process. Cheers Evan.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
You can use ethereal to analyze the network traffic. It will tell you everything that is sent across the line.  http://www.ethereal.com
Created attachment 195830 [details] A filtered ethereal (libpcap) capture of Firefox network traffic (gzipped) I have again entered the single word "abc" into my Firefox address field and hit enter. This time I have captured, using ethereal (as suggested), the network traffic. I have attached a filtered dump of what ethereal captured showing all traffic from-and-to my pc (ip address 10.34.251.160). Open this dump using ethereal or some other compatible application. I noticed that Firefox doesn't make the request to find Google until 521 seconds (8:41min) after my initial request (see packet #1413). I think by looking at the capture, that Firefox tried to resolve "abc" 8 min 41 sec Firefox continually tried to resolve. It tried despite recieving numerous DNS query responses of "no such name" and "server failure". BTW, During this period, Firefox has blocked all activity! I cannot stop the address search or do any other interaction with Firefox. This includes other Firefox windows (which I assume are part of the global process). I suppose I don't care that it tries so hard to resolve the address. What bothers me is that I don't understand why Firefox would do the search in a manner that blocks all user interaction with it's process via any of it's threads. To stop the search I need to kill the Firefox application via the Windows task manager. Of course I then have to restart Firefox. An issue if I had lot's of tabs open for reference. I hope this information helps to solve this bug mystery. If I can help in any other way, please let me know. I love Firefox and would like to see it not hang. Cheers, Evan.
Evan - there has been much going on since September and your reported Firefox version(s) are already relatively old a build to analyze bugs against now. The problem you are reporting may well have been fixed already. Could you please download a recent version or nightly build from <http://www.mozilla.org/releases/nightly.html>, and then let us know if you still see this problem? Many thanks, Cigno
I no-longer work at Qantas and hence am not behind their strict proxy / firewall. That said, their proxy / firewall never interferred with Opera or IE. In short, I can no longer attempt to repeat the bug and am happy for it to close.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago → 12 years ago
Resolution: --- → WORKSFORME
The behavior still persists. At home, FF works like a charm but at work behind a proxy, if I enter something like 'y.net' in the address bar and press Enter, FF freezes for a good 20-25 seconds before it comes back. Interestingly, IE8 and Chrome both do not exhibit this behavior and stay responsive while processing this request. Btw, I'm running FF3.0.11 on IBM Thinkpad T60 1.8Ghz 2.5GB RAM. I realize it's not the important of bugs, but ran into this bug report and thought I should report that this behavior still persists in FF.
You need to log in before you can comment on or make changes to this bug.