RESOLVED INVALID 20096
Safari doesn't offer to save passwords on some sites because HTMLInputElement::value() returns empty string
https://bugs.webkit.org/show_bug.cgi?id=20096
Summary Safari doesn't offer to save passwords on some sites because HTMLInputElement...
Tim S
Reported 2008-07-18 10:55:26 PDT
http://forums.freshalloy.com http://forum.teamxbox.com Enter credentials in the login forms with password-saving enabled and observe you are not prompted to save your password. After some digging I found that for these HTMLInputElements (the username and password fields), HTMLInputElement::value() returns an empty string even though valid text was input into the fields. Perhaps some JS in this forum software strips the fields somehow, or something else is up.. I haven't found the underlying cause.
Attachments
Eric Seidel (no email)
Comment 1 2008-07-18 11:45:44 PDT
This bug is probably a Safari bug, and thus belongs in Radar, but it's possible that WebKit is to blame here. I've CC'd Adele, who wrote most of our modern form controls (and would know who in Safari land does the auto-complete stuff these days).
Tim Steele
Comment 2 2008-09-04 22:21:26 PDT
For the record, this bug also causes Chromium's password manager to fail on any site using the same forum software as those listed, because it gets an empty string from the HTMLInputElement and decides there is no login in progress. I noticed that Safari had the same issues with these sites and guessed both browsers were suffering from the same underlying cause.
Tim Steele
Comment 3 2009-11-30 10:53:18 PST
FYI - Turns out this isn't a webkit bug, but I'm willing to bet Safari fails for the same reason Chromium fails (more affected URLs include livejournal.com, websms.rogers.page.ca, any vBulletin based web form (already listed below), and others found at http://crbug.com/28910). The sites install onsubmit handlers to swap out passwords with hashes, so by the time the FrameLoader is told to submit the form, the value of the password input is empty (confirmed by observing a callback from Javascript clear the variable just before submitForm in the affected cases, and no such callback occurs in normal cases). Other sites just r handle the POST using XHR (which doesn't seem to go through the same code path) and return false; in onsubmit. I guess this is resolved from a webkit perspective.
Note You need to log in before you can comment on or make changes to this bug.