I am unable to get single signon to work at all, with either normal HTML forms or browser-generated forms. Let me know if I'm doing something wrong. Steps to reproduce: 1. Clean User Profile (delete Users50\Default directory) 2. Launch 5/14 build (win32) 3. Enable SingleSignon thru preference pane, checking the 'automatically prefill usernames and passwords box.' (Verified by looking at prefs50.js file that signon.rememberSignons gets set to true.) 4. Goto a username/password form such as http://slip/projects/marvin/wallet/login.html 5. Fill in username/password and press login. Results: Form is submitted with no feedback. Expected Results: Should be asked for a password, either at the console or at a pop-up dialogue (not sure which). Also, returning to these sites should have usernames/passwords pre-filled (they're not). Tried setting the wallet.useDialogs pref to true, also, which didn't seem to have any effect.

Okay, my test case at http://slip/projects/marvin/wallet/login.html doesn't seem to invoke single-signon. I based it on the bugsplat login at http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser which does invoke it. Any ideas why my page doesn't trigger single-signon? Also, browser-generated forms such as http://www.roamers.com/users/paulmac aren't triggering single-signon. I can write a separate bug if you'd like.

updating summary

The reason the test case at http://slip/projects/marvin/wallet/login.html doesn't trigger single signon is because the html is invalid. Specifically, the text and password elements are of the type: <input size=35 id="uname"> There is no "id" attribute listed in the html spec and I have no idea what the intended use of this attribute is in this test. Furthermore, the test does not have a "name" attribute. Single signon uses the name attribute to determine that fieldname and if there is no such attribute it ignores the field. That is why this test did not trigger single signon. (Note: if "id" was changed to "name", then this test would probably trigger single signon although I didn't try it.) It should be noted that both single singon and wallet are based on heuristics which obviously will not work for every site. It is hoped that at least they will work for most sites. Now for the second item addressed in this bug report. The reason that browser-generated forms are not triggering single signon is because last week davidm put an "#ifdef 0" around the single-signon call in mkaccess.c. Although I was dismayed by his doing so, I can understand his motivation -- he did this as a stopgap measure until modal dialogs on the netlib thread are available and such dialogs will not be available until necko lands. Closing this bug report out as invalid.

The reason the test case at http://slip/projects/marvin/wallet/login.html doesn't trigger single signon is because the html is invalid. Specifically, the text and password elements are of the type: <input size=35 id="uname"> There is no "id" attribute listed in the html spec and I have no idea what the intended use of this attribute is in this test. Furthermore, the test does not have a "name" attribute. Single signon uses the name attribute to determine that fieldname and if there is no such attribute it ignores the field. That is why this test did not trigger single signon. (Note: if "id" was changed to "name", then this test would probably trigger single signon although I didn't try it.) It should be noted that both single singon and wallet are based on heuristics which obviously will not work for every site. It is hoped that at least they will work for most sites. Now for the second item addressed in this bug report. The reason that browser-generated forms are not triggering single signon is because last week davidm put an "#ifdef 0" around the single-signon call in mkaccess.c. Although I was dismayed by his doing so, I can understand his motivation -- he did this as a stopgap measure until modal dialogs on the netlib thread are available and such dialogs will not be available until necko lands. Closing this bug report out as invalid.

The id attribute is classified in section 7.5.2 of the HTML 4.0 - I have a copy in my office if wish to peruse. It is used to reference elements from scripts. (I use it to verify that the correct signons are 'remembered'). However, I buy your argument that the name attribute must be set, in fact I see a comment in section 17.4 of the HTML 4.0 spec that '...attribute name required for all but submit & reset...' I added name attributes to my test case and single-signon triggered correctly. Verifying the first part of this bug invalid. I'll file a separate bug to myself to verify browser-generated forms once necko lands.

Sorry for entering my comment above twice -- I don't know how that happened. As for the "id" attribute, OK I can believe it is in html 4.0. I wish someone would update the spec on the devedge page because that is what I use as my reference. Furthermore, the "id" attribute was not even used correctly in your example. The values of the "id" attribute did not match the values that you were testing for in javascript. That is why I had no idea what the purpose of the attribute was.

beating a dead horse here, but my id attribute was used correctly, I just have a var set above the if statement that you missed. Sorry the test case is so ugly - I had to rewrite it about 4 times to make it work since gecko and 4.x interpret javascript quite a bit differently.