Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 SeaMonkey/2.23 My Password Manager database contains user IDs and passwords for both <http://slashdot.org/> and <https://slashdot.org/login.pl?op=userlogin>. To login to SlashDot with JavaScript enabled, the former throws up a script-generated login dialogue. To login to SlashDot with JavaScript disabled, the latter Web page is used. Despite the advertised closure of bug #355063, Password Manager does not fill-in the user ID or password -- even when prompted by all or part of the ID -- at <http://slashdot.org/>. Instead, to login, I must disable JavaScript and login at <https://slashdot.org/login.pl?op=userlogin>. I will try all this in Safe Mode later.

I recreated the problem in Safe Mode. I purged all entries from the Error Console, set signon.debug;true, and then went to <http://slashdot.org/>. I selected the item Login on the green bar near the top-right of the page. I then copied all Error entries to a text file, which is attached. NOTE: Copying entries from the Error Console would be much easier if there were a capability to copy an entire entry-type. Instead I had to copy each entry individually. There were far too many Warning entries to even attempt such an effort. I will submit a new bug on this.

re my comment #1: No new bug required. This is bug #88057 from 2001, which finally seems to be getting some attention towards a fix.

The content of attachment 8349557 [details] doesn't contain any login manager output, so isn't useful.

Re comment #3: This bug was submitted per the comment at <https://bugzilla.mozilla.org/show_bug.cgi?id=355063#c81>, where I was requested: "Please include output from the browser console with signon.debug set to true for password manager bugs." The attachment in this bug is my response. Whether it does or does not contain any Password Manager entries, it is indeed what I was requested to provide. Please let me know if you wish Warning entries instead of Error entries. However, that will take considerable effort until bug #88057 is fixed.

(In reply to David E. Ross from comment #4) Using the browser console it's now easy to select everything. Can you provide the requested data? I think you can filter by "Login Manager" to catch it all but I'm not sure.

(In reply to Matthew N. [:MattN] from comment #5) > (In reply to David E. Ross from comment #4) > Using the browser console it's now easy to select everything. Can you > provide the requested data? I think you can filter by "Login Manager" to > catch it all but I'm not sure. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 SeaMonkey/2.25 Using the latest end-user release of SeaMonkey, I still cannot select and copy all entries in the Browser Console. As far as I can determine, no work is being done on bug #88057 to make that a capability.

(In reply to David E. Ross from comment #6) > Using the latest end-user release of SeaMonkey, I still cannot select and > copy all entries in the Browser Console. As far as I can determine, no work > is being done on bug #88057 to make that a capability. The "Browser Console" is not the same as the error console. Find it from Tools > Web Developer > Browser Console. If Seamonkey doesn't have that then you can try reproducing this in Firefox or reading the logs in the Error Console to look for relevant lines yourself or taking screenshots of it (preferably after filtering).

Please do not add me to the CC list. As the bug originator, I already receive copies of updates.

Re comment #7: According to my query at the mozilla.dev.apps.seamonkey newsgroup, SeaMonkey does not have a Browser Console. It seems to me that it would be far more simple for someone who already has Firefox installed to provide the wanted Browser Console data than for me to install (and then remove) Firefox just for this purpose.

(In reply to David E. Ross from comment #8) > Please do not add me to the CC list. As the bug originator, I already > receive copies of updates. I didn't the needinfo feature does this.

I can't reproduce this on slashdot.org or beta.slashdot.org on either of the the login forms (script-generated and noscript). Please make sure that the "signon.useDOMFormHasPassword" pref is true (this is will always be true from 92 on). Without more data => WFM.

(In reply to Matthew N. [:MattN] from comment #11) > I can't reproduce this on slashdot.org or beta.slashdot.org on either of the > the login forms (script-generated and noscript). Please make sure that the > "signon.useDOMFormHasPassword" pref is true (this is will always be true > from 92 on). Without more data => WFM. Did you try this with SeaMonkey in Safe Mode? If so, which version of SeaMonkey? If not, this bug is still open.

(In reply to David E. Ross from comment #12) > Did you try this with SeaMonkey in Safe Mode? I sure hope not. If you've got a SeaMonkey specific bug, go file a bug against SeaMonkey.

There is no point in opening a new bug report merely to change the product and component, especially when the current bug report already contains a valid description of the problem.

I have solved the problem with this bug. The JavaScript popup for logging into Slashdot is for <http://slashdot.org/>. With JavaScript disabled, the login Web page is <https://slashdot.org/login.pl?op=userlogin>. My Password Manager only had an entry for the https, not for the http. I now have entries for both, and both work.