53554 - Proxy authentication login has no effect

Status: VERIFIED WORKSFORME

(Core :: Networking, defect, P3)

Description

[michael.t.loeffler]

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.

Comment 1

[Gabriel]

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

Comment 2

[Dennis Jørgensen]

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)

Comment 3

[Matthew T (active 1999-2002)]

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.

Comment 4

[Matthew T (active 1999-2002)]

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

Comment 5

[Tom Everingham]

verif. DUP

Comment 6

[Gagan]

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

Comment 7

[Jim Roskind]

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

Comment 8

[michael.t.loeffler]

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

Comment 9

[Jim Roskind]

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.

Comment 10

[michael.t.loeffler]

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.

Comment 11

[michael.t.loeffler]

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.

Comment 12

[Jim Roskind]

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).

Comment 13

[michael.t.loeffler]

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.

Comment 14

[Matthew T (active 1999-2002)]

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

Comment 15

[michael.t.loeffler]

Sorry, still new at this bugzilla thing...

Comment 16

[Matthew T (active 1999-2002)]

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.