From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.13 i686) BuildID: 2000091312 I set and confirmed proper manual proxy settings, and try to go to a URL outside the firewall. The login popup appears, I type in user/pass, hit OK and nothing happens. Each time I try to go to a URL outside the proxy login dialog pops up again. Reproducible: Always Steps to Reproduce: 1.Setup manual proxy settings 2.Go to URL outside firewall 3.Answer user/pass dialog with OK Actual Results: Nothing Expected Results: Page should appear Used to work in M17 build and other nightly builds until around 9/16. An odd change in the behavior of the auth popup is that it should give the message "Enter user name for NETCACHE at 123.45.67.8" but instead of the IP address of the proxy server it fills in the host name from the URL I want to go to. Maybe this is a clue.

The browser has the same behavior on my computer !!!!! :-((((

I see this too. Additional information, that probably doesn't mean anything: The console states that the page is loaded succesfully (which it isn't, obviously)

Reproduced with 2000092212 build, Mac OS 9.0. This be dogfood. See also bug 50141 and bug 47591 -- one or both of those could be dups, but they occur in different cases from this bug so I won't mark them as such. That `additional information, that probably doesn't mean anything' may in fact mean something. Mozilla appears to give up on loading the document (`Document: Done' displayed, and throbber stops) just *before* the authentication dialog is shown. But if the problem was with the authentication process itself, one would expect this to happen immediately after the dialog was dismissed.

*** This bug has been marked as a duplicate of 53182 ***

verif. DUP

This is an incorrect dup. This deals with proxy auth and not basic auth which the dup is all about.

Is this happening on the Netscape branch, or the trunk??

I just confirmed this behavior still exists on the latest Linux nightly build, Build ID 2000100221. I assume that is the trunk.

I still need to hear what the status is on the branch. The bulk of Netscaper's are working on the branch, and the dogfood status is meant to demand attention from them to help others use the product day-in-day-out. I'd need to hear this is a branch problem before I can dogfood-plus it at this point.

I have no way I know of to get the commercial branch code, and unfortunately I have no facility to build it even if I did, but if you can point me to a Linux binary I'd be happy to test it.

Sorry, after a bit of rummaging around in the ftp site I noticed the new -MN6 naming convention, I downloaded and tried the Linux version of Build ID 2000100309, with exactly the same results.

Since this is a branch problem, I'll put it on the rtm nomination list. Proxies are not used extensively (with logins) around netscape, so I'm not sure who is being blocked (is there a class of testing being done?). For now, I'll mark this as dogfood-minus (pending hearing about folks that are blocked). I can believe this is a problem for a notable portion of our market... so hopefully gagan will weigh in with percieved market share issues (as will others on this bug). Gagan can also make a call on whether this has a shot at being fixed for rtm (I'm sure there are a lot of bugs on his list :-( :-( ) and can decide if he has time to try for a fix (re: rtm-minus vs rtm need info).

Good news, this bug appears to be fixed in the latest Linux Build ID: 2000100421. Appears it was related to the basic auth problem in bug 53182 after all. I tested the netscape branch Build ID: 2000100409 and it's still broken.

Reopening. This should either be marked worksforme, or re-resolved as a dup of bug 53182.

Sorry, still new at this bugzilla thing...

That's ok, Michael. For future reference -- a bug should only be marked fixed by a programmer who fixed it, or by someone acting on their behalf. Verified worksforme, build 2000100520, Mac OS 9.0.