example: http://user@foo.bar expected: authentication dialog (sheet) with 'user' pre-filled in username field actual: blank username and password dialog (sheet) I'm using this with HTTP basic authentication, but it should be the same with digest, FTP, etc. build 2002041712

This would have to be done by the netwerking layer before calling on the password manager. Reassigning.

Duplicate of "RFE: Auth dialog should be prefilled with username when using http://username@somehost.somedomain" *** This bug has been marked as a duplicate of 66177 ***

Reopening and changing summary to cover FTP case that isn't covered by bug 66177.

I think this bug is invalid for the existing ftp code. The ftp code currently prompts only for username and password when the uri doesn't have a login and anonymous login fails. At all other times, it just prompts for password.

Clearly, this belongs on 'Stupid Reporter Tricks'. I know I tested it, but I must've spaced and typed http in place of ftp...

(hates vauge bugs that morph). Please restate what you want. I think this is INVALD b/c it already does that, w/ the exception of FTP-proxy (bug 149103).

resolving as invalid per comments 4 and 5 (may also have been a duplicate of bug 66177 but I can't easily confirm that)

verifying as 'stupid bug'

REOPEN, this is valid. #4 in this bug is incorrect, per bug 124561. Here's some more clarification from bug 61177: ------ Additional Comment #5 From Bill McGonigle 2002-04-25 07:41 ------- In the dup bug I filed, bug 139851, I suggested this should happen for FTP also. I notice this bug is under Networking::HTTP. Would the work done in Networking::HTTP get us FTP support too? ------- Additional Comment #6 From Darin Fisher 2002-04-25 13:36 ------- nope, this bug would have to be solved individually for FTP. --- What people want for HTTP is a username/password dialog that has both fields w/ text entry. The current implementation prefils the user in a label, which cannot be changed by the user. This creates problems in some situations. For example, there is no way to get a user-password auth via content (see bug 202419).