From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.1+) Gecko/20010622 BuildID: 2001062204 PSM no longer pops up to ask if you want to store a password, and sites that have previously remembered passwords no longer fill in the form fields Reproducible: Always Steps to Reproduce: 1. go to any site with a login/password you have previously saved 2. PSM does not fill in fields Also 1. Go to site where you have not saved password and manually fill them in. 2. PSM does not ask if you want to rememeber the password. Actual Results: PSM does not fill in fields, does not ask if you want to remember passwords Expected Results: PSM uses previously saved passwords or asks for use of new ones I have marked this as critical as data is lost ie, saved passwords are not longer available from PSM
John, this feature works for me on the 0.9.2 branch build from today (06/25). Can you try that build and report back? Also, can you try out this feature on a new profile?
This is not working for me on 6/25 Win98, Linux, Mac or WinNT branch builds. Setting to blocker. OS =all
John, Have you ever blown away the key3.db file associated with the profile you're seeing this with?
reassigning to Steve Morse. John Unruh reports the same bug when using "obscure". It works for me and mcgreer, so I don't know what the real nature of the problem is.
Moving to Browser/Password Manager
Okay, I have checked with today's (25th June) build, and the problem is still there. I also created a new profile and the problem is still as described from a virgin profile When re-installing an older version (15th June), everything is working again (except for PSM from the mail start window, which I previously reported). With regards to the key3.db, I've never knowingly trashed it, and it is still there with data. As this file still seems to work correctly when reverting back to an older version of Mozilla, this seems unlikely to be the problem.
Am unable to reproduce. With a build that I made last night this is working fine. Have tested this on both NT and linux. junruh and/or firstname.lastname@example.org, can you reproduce this failure on the trunk builds or only on the branch?
6/26 WinNT branch build - fails. 6/26 Win98 trunk build - fails.
I've only been testing on the builds labelled "latest nigthly builds" (whatever they are). Sometime between 15th June and 22nd June this problem was introduced
I'm testing the in-house builds from here. ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/
Can you give me the specific URL that you are using in your testing.
mail.yahoo.com or https://junruh.mcom.com/testplans/sdr.html
Do you mean the mail.yahoo.com that has the following form tag? :-( <form method=post action="http://login.yahoo.com/config/login?5dtogmcbvvkdp" autocomplete=off name=a>
And the other example, namely https://junruh.mcom.com/testplans/sdr.htm, works fine when I copy it to my own site which is http. I do see the failure on your https site. So the problem has to do with https which means I'm bouncing it back to the security group. Also changing the summary from PSM manager no longer works to Password manager does not work on https sites
I'm getting my builds from: http://ftp.mozilla.org/pub/mozilla/nightly/latest/
Steve, I don't agree yet with your comment "So the problem has to do with https". SDR works for me on both these sites: http://junruh.mcom.com/testplans/sdr.html https://junruh.mcom.com/testplans/sdr.html I tried this on my profile, and on a new profile. It works in both cases. This isn't a crypto problem. It's something lower down. Another clue: I cannot open the View Password Manager window, though others can so without any trouble. I am able to open that window with a fresh profile. In other words, there are some really strange things going on, perhaps at a lower level that either SDR or the View Password Manager. Please see if you can track this down. There's something fishy going on here.
OK, I'll prove my comment: "So the problem has to do with https" I set a breakpoint in extensions/wallet/src/singsign.cpp line 2048 which reads ioService->ExtractUrlPart (passwordRealm, nsIIOService::url_Host, 0, 0, getter_Copies(strippedRealm)); Then I step into ExtractUrlPart (which is nsIOService.cpp) and I get to line 506 which reads: rv = GetParserForScheme(scheme, getter_AddRefs(parser)); This call is returning an error code when scheme is https but not when schem is http. The failure is coming at line 455 of that file which reads rv = parserList->GetNext(getter_AddRefs(entry)); You can verify this by pressing the submit button on junruh's https site (https://junruh.mcom.com/testplans/sdr.htm) and then on my http site (http://peoplestage/morse/bug.htm) which mirrors his site exactly.
Bob, please run your test again. I am definitely not getting a failure on junruh's http site. On that site I get the password-manager dialog asking if I want to save the values. This is completely consistent with my claim that the problem is https related. Shall I reassign this back to your group or are you still not convinced?
Using a new profile, I can't get neither http://asdstg-s02.websys.aol.com/staging nor etrade login to ask me if I want to save the passwd. Using Linux 0.9.2 2001062604 build.
I'm pretty sure I also had this failure on non-https sites when I had one of the faulty versions installed.
Please don't morph this bug. The problem in this bug involves password manager not working with https sites. And this is demonstrated with junruh's https test page. I'm updating the summary line to make that explicit. The problem with etrade I'm sure is the same one that I dismissed in my comment of 2001-06-26 10:29 -- namely the "autocomplete=off" attribute. As such, any bug report that claims that password manager doesn't work with etrade or with mail.yahoo.com is invalid.
moving to PSM
As Steve has pointed out, the code is failing during the parsing of urls with https. This parsing happens in mozilla/netwerk/base/src/nsIOService.cpp. There has been quite of few changes to this code in the past week and my suspicion is that there has been a regression here. Assigning to dougt.
found the problem....
steve, can you verify that this fixes the problem? This probably should be fixed on the branch.
I applied the patch and it indeed fixes the problem r=morse
Checked into the trunk: Checking in nsIOService.cpp; /cvsroot/mozilla/netwerk/base/src/nsIOService.cpp,v <-- nsIOService.cpp new revision: 1.98; previous revision: 1.97 done Should we check this into the branch?
I would think that would be a good thing to do.
a=chofmann for the branch
Checked into 0.9.2. Closing. Re-open if you guys need to but it looks like it was held open for the 0.9.2 branch.