243149 - Hostname and port appears where 'Use Password Manager to remember these values.' usually is.

Status: VERIFIED FIXED

(SeaMonkey :: Passwords & Permissions, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Build ID: 2004-05-09-07

Steps to Reproduce:

1.  Load http://iuware.iu.edu/wintitle.asp?softid=vsnet01
2.  Right click on the 'Download' link and use the 'Save Link Target As' context
menu option at:

Download Option 1
Download the software in one large 390 MB file.
setup.exe 	390 MB 	Download


(Note, this WORKS FINE if you just click on Download
3.  Examine the resulting authentication box that comes up.

Expected Results:

'Use Password Manager to remember these values.'

Actual Results:

The string above is replace by:

'iuware-web001.uits.indiana.edu:443 (iuware-web001.uits.indiana.edu)'

Comment 1

[Darin Fisher]

I can reproduce this using a 1.7 branch build.  I wonder if the phishy auth
prompting patch introduced this somehow.

investigating...

Comment 2

[Darin Fisher]

Hmm... there's some bogus code here:

http://lxr.mozilla.org/mozilla/source/xpfe/communicator/resources/content/contentAreaUtils.js#475

nsIPromptService::PromptUsernameAndPassword does not take a realm parameter. 
Instead, it takes the text for the checkbox in the position where the realm is
being passed.  that's consistent with what we see in the dialog.

the changes to contentAreaUtils.js are dated 2002-03-05, which means that it was
made for moz 1.0.  see bug 116279.  it appears i sr='d it too :-(

it looks like this has probably been broken since it landed b/c
PromptUsernameAndPassword's signature has not changed since 10-Apr-01.

I can reproduce this bug using Mozilla 1.4.

Comment 3

[Darin Fisher]

The correct fix here is probably to not implement nsIAuthPrompt in
contentAreaUtils.js.  Instead, contentAreaUtils should get a hold of a reference
to the same nsIAuthPrompt implementation used by nsDocShell.  And, that means
that it should be using the nsIWindowWatcher service's getNewAuthPrompter method.

-> me

Comment 4

[Darin Fisher]

Attachment: v1 patch

simple patch.  just duplicate getInterface implementation from
nsProxyAutoConfig.js.  needed to patch both seamonkey's contentAreaUtils.js as
well as firefox's forked contentAreaUtils.js.  the same patch worked for both.

Comment 5

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

this is a duplicate of bug 159089; marking the dup the other way round I guess,
as this bug has a patch...

Comment 6

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

*** Bug 159089 has been marked as a duplicate of this bug. ***

Comment 7

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

Comment on attachment 148085 [details] [diff] [review]
v1 patch

hmm, nsIPrompt also has a method called promptUsernameAndPassword... with
different parameters. deserves a price for obfuscation.

this confused me into thinking
nsPrompt::nsIAuthPrompt::PromptUsernameAndPassword was wrongly implemented...
but I was looking at nsIPrompt's impl.

I also believe this makes it impossible to implement both interfaces on the
same object in javascript. ah well.

Comment 8

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

thanks for making this patch!

Comment 9

[Daniel Veditz [:dveditz]]

Comment on attachment 148085 [details] [diff] [review]
v1 patch

sr=dveditz

Comment 10

[Daniel Veditz [:dveditz]]

Comment on attachment 148085 [details] [diff] [review]
v1 patch

a=dveditz for 1.7

Comment 11

[Daniel Veditz [:dveditz]]

Nice to have, but blocking1.7-minus because we wouldn't hold for this. (lived
with it almost two years at least given bug 159089)

Comment 12

[Darin Fisher]

fixed-on-trunk
fixed1.7

Comment 13

[[e-mail]]

Comment on attachment 148085 [details] [diff] [review]
v1 patch

>+    Components.returnCode = Components.results.NS_ERROR_NO_INTERFACE;
>+    return null;
Neat. I always thought you had to throw C.r.NS_ERROR_NO_INTERFACE;

Comment 14

[Darin Fisher]

> >+    Components.returnCode = Components.results.NS_ERROR_NO_INTERFACE;
> >+    return null;
> Neat. I always thought you had to throw C.r.NS_ERROR_NO_INTERFACE;

yeah, this is nice because it avoids the XPConnect exception output in the [JS]
console.

Comment 15

[Olivier Cahagne]

*** Bug 195780 has been marked as a duplicate of this bug. ***

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED for me using trunk 2004-05-12-08 on Windows XP.