(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #98017 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=98017 Imported into Bugzilla on 02/11/99 19:49) -- Bugs reported from SGI - 4.03 RTM - Horrendous DNS-related delays Basically, despite the so-called "fix" of having DNS lookups in a separate helper process, Navigator still hangs (no screen updates in *any* window, incl. news/mail) for up to several *minutes* when doing some DNS lookups. These are not always failures, in fact they are usually perfectly good domain names. There is no pattern to when it will hang, but it seems to happen often. I end up having to kill the netscape process after 2-3 minutes. As far as I am concerned this makes the product basically unusable, and would give up on it, except that it is just as bad in previous versions. --- When user change proxy configuration from "Automatic" to "Manual", it provides a vast improvement. Netscape does *not* hang in all windows during delayed DNS queries. The browser window that caused the delayed query is redrawn and you usually can use the Stop button; other windows are normal. --- This problem still occurs in 4.04 RTM. Would like to see it being fixed for 4.05. Can anything be fixed for "Automatic" proxy configuration in 4.05?

Please give some feedback on this bug report once you have investigated further. We need to find out: 1) Fix is easy, no side-effect. 2) Fix is hard, but there is a work around. 3) Fix need to be on SGI setup. Give suggestions. This is not a taker for 4.05 In yet. We need to have some investigation done first. Reassign to Arun. He is interested in this problem. Adding jwz,montulli,friedman and dp to the bug report for input.

adding valeski to cc list. will most likely have to move this to target fix version 4.06 unless we learn what the problem is and find an safe fix in the next couple of days.

adding valeski to cc list. will most likely have to move this to target fix version 4.06 unless we learn what the problem is and find an safe fix in the next couple of days.

Where is the automatic config url pointing? And/or what does the pac file look like that the automatic config url points to?

There is some information about the SGI configuration at http://grok/escalations/sgi/sgiconfig.htm with a link to the most updated copy of the SGI doc at the bottom.

I suspect that the problems have something to do with SOCKS_NS settings. Found a bunch of Linux guys also complaining about SOCKS_NS (a dejanews search brings them up) and resulting DNS hangs. dns_socks_kludge in unix-dns.c seems to be relevant. Is SGI using socks version 4 or version 5 ?

umesh/alistair/var, can you track down the SOCKS version number?

no update from SGI. we suspect this is a problem in there network config. moving off the 4.05 to 4.06 until we learn more.

I finally got the answer from SGI today. They are using SOCKS version 4.

If they're using SOCKS version 4, everything should work in theory. They need to set SOCKS_NS variable, only if there is a firewall between their network and the DNS servers. If nothing else works, we could give them a copy of 4.0x client with the DNS trace output turned on to learn more about what's going on.

Reassign to web group for them to find an owner of this bug.

Chris, please find a new owner to really look into this problem.

Changing TFV to 5.0.

Another one for Spence!

this is a really old and crusty bug, any idea whether it's still relevant? if so, do we have the same problems in seamonkey?

If this is indeed TFV/5.0 then who is handling our SGI builds? Are we still supporting it? Last I heard from akkana, people at SGI are trying to maintain SGI builds... Marking LATER for now.

lets try var@sgi.com

Note that this is a problem on the old 4.x codebase, may or may not have anything to do with the new codebase.

SGI entered this bug against Communicator 4.03 back in Sep 24 1997 03:42:24PM then escalated it to Netscape's defect bug system. Then it got LATER'ed to 5.0 so is now assigned back to SGI to fix in the 5.0 code... I guess it would be OK for us to accept this bug. The only problem is that the 5.0 code hasn't been stable enough on IRIX for us to delve into fixing bugs like this yet so it may take a while to resolve this bug. For SGI purposes this is bug id 528097. Victor A. Riley

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.

Cleared the resolution. (Bugzilla no longer supports the idea that an open bug can have any kind of resolution set.)

spam, changing qa contact from paulmac to tever@netscape.com on networking/RDF bugs

This bug has not been touched for more than nine months. In most cases, that means it has "slipped through the net". Please could the owner take a moment to add a comment to the bug with current status, and/or close it. Thank you :-) Gerv

should leave this one alone. if someone comes back to work on the sgi port they could pick up on the work

qa to me.

RESOLVED/INVALID per jaworski, this can be wrapped up. There is no complete problem description, esp the offending .pac file.

VERIFIED: looking more carefully at this, we also have completely new SOCKS code now.