158252 - should prompt only once for username:password per realm per page [was: Password window keeps re-appearing and won't go away]

Status: RESOLVED INCOMPLETE

(Core :: Networking, defect)

Description

[alphawolf_]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a+) Gecko/20020713
BuildID:    2002071308

When you go to the URL listed, the password dialog shows up, but will not go
away no matter what you do; hit ok, cancel, type in a fake password, etc. Only
way to terminate is to hit control-alt-del and close mozilla completely.
Somebody who is more technical than me ought to have a look at what exactly is
going on here before the website updates and we can't reproduce this bug anymore.

Reproducible: Always
Steps to Reproduce:
Just go to that URL

Actual Results:  Password dialog shows up and will not go away

Expected Results:  Should be able to just hit cancel and the dialog shouldnt
show up again.

Mozilla users become a potential target if some malicious webmaster wants to
cause you problems, and since you have to hit control-alt-del to do anything
else, its a pretty bad way to exit, and you could lose any form changes, etc,
without any way to copy/paste elsewhere (which it did to me), hence I am marking
it critical.

Comment 1

[Terri Preston]

I see this behavior using win XP branch build 2002071808, I can eventually close
the dialog by pressing the X in the upper right hand corner, but agreed, not a
nice way to exit, marking new

Comment 2

[Stephen P. Morse]

Looks like nsHttpChannel::OnStartRequest keeps getting called repeatedly, and it 
in turn keeps calling on the password manager to put up the authentication 
dialog.  The stack trace at the time the dialog is displayed is shown below.

Reassigning to http auth since they are the ones that are looping.

USER32! 77e72c30()
nsXULWindow::ShowModal(nsXULWindow * const 0x048bdbe0) line 279 + 31 bytes
nsWebShellWindow::ShowModal(nsWebShellWindow * const 0x048bdbe0) line 1109
nsContentTreeOwner::ShowAsModal(nsContentTreeOwner * const 0x03ce3254) line 449
nsWindowWatcher::OpenWindowJS(nsWindowWatcher * const 0x011f0e44, nsIDOMWindow * 
0x02dd04fc, const char * 0x00f3aa00, const char * 0x00f3b100, const char * 
0x00f3b0dc, int 0x00000001, unsigned int 0x00000001, long * 0x0486ff40, 
nsIDOMWindow * * 0x0012f2c8) line 739
nsWindowWatcher::OpenWindow(nsWindowWatcher * const 0x011f0e40, nsIDOMWindow * 
0x02dd04fc, const char * 0x00f3aa00, const char * 0x00f3b100, const char * 
0x00f3b0dc, nsISupports * 0x03a50448, nsIDOMWindow * * 0x0012f2c8) line 457 + 48 
bytes
nsPromptService::DoDialog(nsPromptService * const 0x0138787c, nsIDOMWindow * 
0x02dd04fc, nsIDialogParamBlock * 0x03a50448, const char * 0x00f3aa00) line 629 
+ 77 bytes
nsPromptService::PromptUsernameAndPassword(nsPromptService * const 0x01387878, 
nsIDOMWindow * 0x02dd04fc, const unsigned short * 0x047829a8, const unsigned 
short * 0x03d17088, unsigned short * * 0x03b05028, unsigned short * * 
0x03b7ef00, const unsigned short * 0x03a430e8, int * 0x0012f638, int * 
0x0012f448) line 466 + 39 bytes
nsPrompt::PromptUsernameAndPassword(nsPrompt * const 0x0480b7c0, const unsigned 
short * 0x00000000, const unsigned short * 0x03d17088, unsigned short * * 
0x03b05028, unsigned short * * 0x03b7ef00, const unsigned short * 0x03a430e8, 
int * 0x0012f638, int * 0x0012f448) line 193
si_CheckGetUsernamePassword(unsigned short * * 0x03b05028, unsigned short * * 
0x03b7ef00, const unsigned short * 0x00000000, const unsigned short * 
0x03d17088, nsIPrompt * 0x0480b7c0, unsigned int 0x00000002, int * 0x0012f638) 
line 538 + 40 bytes
SINGSIGN_PromptUsernameAndPassword(const unsigned short * 0x00000000, const 
unsigned short * 0x03d17088, unsigned short * * 0x03b05028, unsigned short * * 
0x03b7ef00, const char * 0x0012f710, nsIPrompt * 0x0480b7c0, int * 0x0012f9c0, 
unsigned int 0x00000002) line 2387 + 36 bytes
nsSingleSignOnPrompt::PromptUsernameAndPassword(nsSingleSignOnPrompt * const 
0x04917db0, const unsigned short * 0x00000000, const unsigned short * 
0x03d17088, const unsigned short * 0x0012f7d8, unsigned int 0x00000002, unsigned 
short * * 0x03b05028, unsigned short * * 0x03b7ef00, int * 0x0012f9c0) line 671 
+ 51 bytes
nsHttpChannel::PromptForUserPass(const char * 0x03bee960, int 0x00000050, int 
0x00000000, const char * 0x0012fb68, unsigned short * * 0x03b05028, unsigned 
short * * 0x03b7ef00) line 1962 + 107 bytes
nsHttpChannel::GetCredentials(const char * 0x0477de18, int 0x00000000, 
nsAFlatCString & {...}) line 1736 + 96 bytes
nsHttpChannel::ProcessAuthentication(unsigned int 0x00000191) line 1599 + 20 
bytes
nsHttpChannel::ProcessResponse() line 571 + 12 bytes
nsHttpChannel::OnStartRequest(nsHttpChannel * const 0x039330dc, nsIRequest * 
0x035b3034, nsISupports * 0x00000000) line 2838 + 11 bytes
nsOnStartRequestEvent::HandleEvent() line 161 + 53 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x0477d89c) line 116
PL_HandleEvent(PLEvent * 0x0477d89c) line 596 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00c50d18) line 526 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x062904f2, unsigned int 0x0000c0ff, unsigned int 
0x00000000, long 0x00c50d18) line 1077 + 9 bytes
USER32! 77e71268()
00c50d18()

Comment 3

[Darin Fisher]

netscape 4.x does not appear to have this problem, but using 4.x to load the
page reveals something very interesting.  it appears that the protected document
is not the main page but actually one of the javascript documents.  here's the URL:

http://subscriber.chello.at/interface/textlinks.js

if i load only that URL in mozilla, it prompts me for a username/password, and
if i cancel the dialog i see the 401 error page as expected.

Comment 4

[Darin Fisher]

ok, i know what's going on now... the problem is that there are multiple (~8)
javascript documents that are password protected.  each one triggers the
password prompt.  if you cancel the dialog 8 or 9 times, it'll eventually load
the page.

4.x on the other hand seems to remember the fact that it couldn't authenticate
anything on that page.  moz should do the same, although fixing this bug will be
tricky.

Comment 5

[Christopher Wanko]

Hey, Mozilla 1.4a (20030326) on Win98 exhibits the same problem on
metalink.oracle.com.

I strongly suggest upgrading the timetable on this bug, since access to Oracle's
tech support is *not* something you want to casually dimiss.

Comment 6

[junkmail1]

Windows XP SP2 with latest Firefox 1.1 beta build (20050508).

I experience the same issue when I go to the menus Tools > Options > Privacy >
View Saved Passwords

Comment 7

[Darin Fisher]

-> default owner

Comment 8

[RNicoletto]

URL in the original bug report is no more valid. Any other way to reproduce?