Proxy authentication login has no effect

VERIFIED WORKSFORME

Status

()

P3
blocker
VERIFIED WORKSFORME
18 years ago
18 years ago

People

(Reporter: michael.t.loeffler, Assigned: gagan)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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

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

Comment 2

18 years ago
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

18 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dogfood
OS: Linux → All
Hardware: PC → All
Summary: Proxy auth login has no effect → Proxy authentication login has no effect

Comment 4

18 years ago


*** This bug has been marked as a duplicate of 53182 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 5

18 years ago
verif. DUP
Status: RESOLVED → VERIFIED
(Assignee)

Comment 6

18 years ago
This is an incorrect dup. This deals with proxy auth and not basic auth which
the dup is all about.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---

Comment 7

18 years ago
Is this happening on the Netscape branch, or the trunk??
Whiteboard: [need info]
(Reporter)

Comment 8

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

Comment 9

18 years ago
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.
(Reporter)

Comment 10

18 years ago
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.
(Reporter)

Comment 11

18 years ago
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

18 years ago
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).
Keywords: rtm

Updated

18 years ago
Whiteboard: [need info]
(Reporter)

Comment 13

18 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 14

18 years ago
Reopening. This should either be marked worksforme, or re-resolved as a dup of 
bug 53182.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 15

18 years ago
Sorry, still new at this bugzilla thing...
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 16

18 years ago
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.