159089 - Checkbox with unknown behavior on password dialog (when using "save link target as")

Status: VERIFIED DUPLICATE of bug 243149

(SeaMonkey :: UI Design, defect, P2)

Description

[Sebastian Biallas]

Build: 2002-07-18-04

If you go to above link you'll get the standard dialog asking for password.
Below the inputline for username and password there's a checkbox and the
description of this checkbox is the hostname.

What is this checkbox good for?
Please enlighten me and make this dialog more decriptive :)

Comment 1

[Sebastian Biallas]

Attachment: screenshot of dialog

Comment 2

[Sebastian Biallas]

On a second view: 
If you follow this link directly, this checkbox has the decription "remember
these values with password manager". This is perfectly ok.
But if you go to:
http://www-i5.informatik.rwth-aachen.de/LuFG/Lehre/SS02/RS/Folien+Uebungen.html
And click on "1-up unkomprimiert" (scroll one page down / "Kapitel 1"), you'll
get the dialog I mentioned.

Comment 3

[R.K.Aa.]

Unable to reproduce on a day old CVS build, Linux.

Comment 4

[Vidar Haarr (not reading bugmail)]

WFM on WinXP trunk build 2002072308.
But should perhaps mark as confirmed, due to screenshot.. ?

Comment 5

[Elmar Ludwig]

I see this on Linux (Mozilla 1.1b, build id 2002072204), but in a different
place, when trying to reproduce bug 159057:

1. Open URL ftp://[e-mail]/pub/
2. Enter any password (none needed, but Mozilla doesn't know this)
3. Right click on the README file, select "Save Link Target As..."

Step 3 seems to work ok once (but the file is not saved, see bug 159057)
and on subsequent attempts consistently shows the following dialog for me:

+-----------------------------------------------------+
|  Enter password for ftp://[e-mail]  |
|   _______________________________________________   |
|  |_______________________________________________|  |
|   _                                                 |
|  |_| ftp://[e-mail]                 |
|        __________   ____________                    |
|       |___ OK ___| |__ Cancel __|                   |
+-----------------------------------------------------+

Confirming. May be related to Password Manager?

Comment 6

[Sebastian Biallas]

The steps to reproduce this weren't correct, sorry.
You have to use (Right click on link)->Save Link Target As... to encounter the
dialog I mentioned. This will also work with the URL link above on this page.
I hope this will make reproduction easier.

Comment 7

[Elmar Ludwig]

Ok, I see the described behaviour when using "Save Link Target As..." from
the context menu of the URL given in the bug report.

Interestingly, this authentication dialog is different from the one that pops
up by simply left clicking on the URL: The funny checkbox is there even when
"Remember passwords" is not checked is the Password Manager preferences. And
if this is enabled, the authentication dialog will neither remember the given
password nor recognize (pre-fill) a previously stored password for the URL.

Raising severity a little (minor loss of function)

Platform -> All/All (I see this on Linux and MacOS X here)

Comment 8

[timeless]

wow

Comment 9

[Stephen P. Morse]

Just for clarity, since the original description for reproducing this bug were
incorrect, let me summarize what the correct steps are:

1. Go To
   http://www-i5.informatik.rwth-aachen.de/LuFG/Lehre/SS02/RS/Folien+Uebungen.html

2. Get to the link for "1-up unkomprimiert" under "Kapitel 1"

3. Right-click on that link and select the menu item "Save Link Target As"

4. Authentication dialog appears containing a checkbox

expected results: checkbox text should be
   "remember these values with password manager"

actual results: checkbox text is the name of the host.

Comment 10

[Stephen P. Morse]

The checkbox text is supposed to be filled in by the password manager's
PromptUsernameAndPassword routines.  Problem is, the entire password manager is
being sidestepped under this scenario.  The password manager comes into play
just fine if you left-click on the link.

Here are the relevant portions of the stack traces showing what happens in both
cases:

1. Normal case -- left clicking on the link

nsPromptService::PromptUsernameAndPassword line 431
nsPrompt::PromptUsernameAndPassword line 193
si_CheckGetUsernamePassword line 557 + 40 bytes << checkbox text generated here
SINGSIGN_PromptUsernameAndPassword line 2447 + 36 bytes
nsSingleSignOnPrompt::PromptUsernameAndPassword line 667 + 69 bytes
nsHttpChannel::PromptForUserPass line 1977 + 107 bytes
nsHttpChannel::GetCredentials line 1751 + 96 bytes

2. Bad case -- right-clicking on link and selecting "Save Link Target As"

nsPromptService::PromptUsernameAndPassword line 431
XPTC_InvokeByIndex line 1994 + 42 bytes
XPC_WN_CallMethod line 1266 + 14 bytes
js_Invoke line 839 + 23 bytes
js_Interpret line 856 + 13 bytes
nsXPCWrappedJSClass::CallMethod line 1193 + 22 bytes
nsXPCWrappedJS::CallMethod line 430
PrepareAndDispatch line 115 + 31 bytes
SharedStub() line 139
nsHttpChannel::PromptForUserPass line 1977 + 107 bytes
nsHttpChannel::GetCredentials line 1751 + 96 bytes

So in the bad scenario, instead of going through password manager and obtaining
the checkbox text, the code goes through some javascript routines.  Specifically
it goes through the promptUsernameAndPassword routine in

   xpfe/communicator/resources/content/contentAreaUtils.js#380

Comment 11

[Stephen P. Morse]

Based on my analysis above, it's clear that this is not a password manager
problem.  Instead the problem either lies in http for not calling the password
manager's routine, or in the routine in contentAreaUtil.js for not setting up
the checkbox message as the equivalent password-manager routine does.

Reassigning the networking-http

Comment 12

[Stephen P. Morse]

And really reasingning this time.

Comment 13

[Darin Fisher]

necko only calls the nsIAuthPrompt given to it via the nsIInterfaceRequestor
nsIChannel::notificationCallbacks.  there's nothing in necko that could explain
this bug.  someone is not setting up the necko request properly.

-> xpapps

Comment 14

[Darin Fisher]

let's try that again...

Comment 15

[Paul Wyskoczka]

nsbeta1+/adt3 per the nav triage team.

Comment 16

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

bug 243149 has a patch...

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

Comment 18

[Sebastian Biallas]

vrfy.