Closed Bug 178561 Opened 22 years ago Closed 21 years ago

keychain password storage doesn't work on this site

Categories

(Camino Graveyard :: OS Integration, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: saari, Assigned: bryner)

References

()

Details

reported by a user that password memory doesn't work on 
https://accountmanager.providentcu.org/provident.html?m2A+Body/ SignOnAM.html
Component: HTML Form Controls → OS Integration
The login at https://onlinebanking.huntington.com/ does not save to keychain,
either.
could this be a dup of bug 174489, where some sites simply avoid activating
keychain?

or, is this a case where the username/passwd was already saved, but returning to
it didn't activate the keychain prompt to prefill the fields?
how wacky --iirc, keychain in chimera has worked in the past for me on
my.yahoo.com. will check again...
btw, i'm using 0.6.0 (Build ID: 2002110415).
using 2002.11.06.04 (on 10.2.1), this wfm on http://my.yahoo.com --there should
not have been checkins since 0.6 that would've affected this... just checked
0.6, and it also wfm. note: while testing this i've been selecting "allow once"
from the keychain prompt dlg.
I'm the user that reported this. If you go to the URL listed, and enter
some bogus Member number and PIN (7 digits and 4 digits respectively
will avoid JavaScript error detection on page), you can submit the form
without any prompt to save the password.

I could not figure out how to get Chimera to save the password for that page. I
tested on my.yahoo.com, and that one does work. The example URL above does not
however.

clarification for my.yahoo.com:

i don't get a password prompt sheet after clicking Sign Out once i'm already
logged into Yahoo!.

i.e., when i launch Chimera, if i visit my.yahoo.com, i'm logged in. when i
click Sign Out and then click Return to My Yahoo!, i do not get a prompt on the
secondary login page.
sorry, i guess i did provide the wrong URL. http://my.yahoo.com/ does, indeed,
wfm. the one that doesn't, after Sign Out, is:

http://login.yahoo.com/config/login?.src=my&.done=http://my.yahoo.com/&partner=&.intl=
On the sample page you list for Yahoo that doesn't work, the form tag 
includes the attribute "autocomplete=off". I've never heard of that, but it 
could be what is keeping that one from working. The Provident Credit 
Union sign on does not have that however. I was thinking perhaps it didn't 
work because the form was submitted by a Javascript instead of a submit 
button? That is a not uncommon way to validate the form prior to 
submission.
hmm. i've never seen that attribute, but i guess that could easily cause it not
not to autocomplete if it's meaningfully named... :)
For the web site https://accountmanager.providentcu.org, it think it doesn't
work because there's a 'clever' Java script that validates the form containing
the userid/password, sets another form with hidden fields and then submit this
other form... there's not much we can do here since Chimera search
userid/password fields only in the _submited_ form.

Thomas, http://login.yahoo.com is not http://my.yahoo.com, that's why Chimera
doesn't pre-fill the password, it stores password based on the hostname of the
web site.

Also, if I remember right the form on http://login.yahoo.com has some special
Java script that will prevent chimera to detect the form submit and therefore,
it won't propose you to store the userid/password. It should work though if you
choose to login in "Secure Mode" (in this case the form doesn't have any Java
script and it works...).

Also, https://webbanking.waterhousebank.com/ doesn't work exactly for the same
reason as https://accountmanager.providentcu.org, there's some Javascript that
process the data on submit and then submit another form...

For https://webbanking.waterhousebank.com/ I can't figure out why it doesn't
work :(.

BTW, Chimera doesn't check the autocomplete field when it comes to find out if
the userid/password can be stored.
well, i don't know if these examples should qualify as Mozilla Tech Evangelism
or be considered valid choices on the part of the web designers and left alone
as exceptions. now that i've seen more examples and understand why they don't
work, i'd be satisfied with an INVALID/WONTFIX resolution on this one.
WONTFIX sounds reasonable to me too. Well... unless Mozilla or Internet Explorer
work for these sites, in this case there's maybe a way which I'm not aware of to
work-around these scripts.
QA Contact: winnie → petersen
wontfix
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.