***Overview Description: The single signon Save Username and Password dialog(Yes, No, Never) does not appear when I try the test at the url noted above. ***Steps to Reproduce: 1) GO to the test page and follow directions. 2) CLick login ***Actual Results: All i get is the warning that I'm submitting insecure information, nothing else. ***Expected Results: I should be presented with the save password dialog ***Build Date & Platform Bug Found: Found on the 2000051608 build on linux. This wil robably be XP but I don't have build to check yet. ***Additional Information: This is a regression and a smoketest blocker.

just for clarity: save password dialog == confirm dialog that asks Yes, No, Never to saving a username/passwd.

claudius, is this really a blocker? ie, is there a username listed in the View Passwords dialog? (from Tasks > Privacy & Security > Password Manager >)

just went thru this to check on linux, and sure enough, there isn't anything saved in the Stored Passwords dialog.

Sounds like a problem that I checked in a fix for at 7:55 this morning. Here's what the problem was: 1. Warren made some changes last night so that the username being stored for mailnews and also ftp was coming up blank. This is a bug and warren knows about it. 2. The signon viewer attempts to decrypt the username before displaying it. 3. The decrypt code was returning a failure errorcode when being handed a blank string to decode. 4. The signon viewer was exiting immediately when it got the decryption error code. Although the blank username was the original error, I checked in a fix so that the decryption code will not return an error message on a blank string. That enabled to the signon viewer to come up in spite of the fact that there was a blank username. So you must have done all of the following if you saw the bug this morning: 1. You are running bits that were generated after warren made his change late last night and before my change of 7:55 this morning 2. You save a password from either mailnews or ftp with this build

Scratch my comment above. I misread the bug report and answered a different question altogether. I'll look into this one immediately.

Problem is on line 3314 of extensions/wallet/src/wallet.cpp. The numForms variable is coming up zero so it looks like there are no forms on the page. I'll investigate further to figure out why that's happening, but offhand it looks like it might be a dom problem. cc'ing nisheeth.

Assigning this one to nisheeth. There's definitely something wrong with the dom. From the information that is being passed to it, wallet is unable to get to the list of forms on the page. Nothing has changed in the wallet code in this area.

Regular form submits are working fine in this mornings builds. Nisheeth and I are investigating this bug. This bug should probably not be holding the tree closed.

joki made some extensive changes to DOM support early this morning. Could that have caused this problem?

This is mine.

Re-assign to myself. This is unrelated to warren's changes. Reducing the severity to critical.

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

Let me stress the importance of this and why it is a blocker. All of wallet and half of single signon (the half having to do with server-generated logins as opposed to browser-generated ones) is completly on the floor now because of this bug. It's a regression that started happening Tuesday morning. Furthermore, since this appears to be a dom-related bug, I'm surprised other things are broken by it as well.

This is top priority for me, Steve. I'll take a look at it today.

uh, this is somehow working now, at least on linux, using the opt comm bits 2000.05.17.16. was there a checkin that i didn't know about? weird.

This is working on today's win32 debug build also. Steve, can you verify this and tell me whether its ok to close out this bug. Thanks!

I'm pulling a tree right now and will test it out tonight. If it works, then I'll close out the bug report.

Yep, it's working for me now. So I wonder who broke it and who subsequently fixed it.

verif wfm, 2000.05.18.08 on linux, mac and winNT.