Value of Autofilled input[type="password"] Shows in DOM as Empty
Reported by
azmer...@gmail.com,
Aug 10 2016
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Steps to reproduce the problem: 1. Create a form with an <input type="passsord" /> 2. Allow Chrome to remember the password. 3. Return to page and confirm by seeing black circles that password has been autofilled. What is the expected behavior? Value of input should be visible to DOM, as it is after user manually types it in. What went wrong? Value of empty is shown as an empty string. Did this work before? N/A Chrome version: 52.0.2743.116 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0 This might be a security feature, but is breaks AJAX form submission, because JS needs to be able to see the value to append it to submission. Additionally, this is not broken in Firefox, Edge, or Safari, only in Chrome.
,
Aug 11 2016
,
Aug 11 2016
Thanks for the report. This is a security measure, working as intended. The password value becomes visible to JS as soon as the user interacts with the page in any way (clicks anywhere or types into the page). @tkonchada: no, this has nothing to do with issue 636461 . Removing RVG, because there is nothing confidential in this report.
,
Aug 11 2016
I'd like to lay out a reason for changing this behavior: AJAX signing forms. When I load up a validation script, Chrome (and only Chrome) shows password fields that have been autofilled as invalid, giving the user an error message saying the field is empty. Because it's being report by Chrome as empty. Users who use autofill want to be able to just click the submit button and go, but they load the page and get a big red X which shouldn't be there. This is broken behavior. It's also not any more secure, because the moment a user interacts with the field, the password is visible anyway.
,
Aug 11 2016
,
Aug 16 2016
So you're just not even going to respond, vabr@?
,
Nov 28 2016
I think this should be reconsidered. This provides a fairly small amount of protection. It's true that that a malicious site could create an iframe to another domain and stealing the user's password. But that site just has to get the user to click on the iframe and the password is given up. It would be better if Chrome simply did not to auto-fill passwords in iframes opened to other domains. Then this limitation wouldn't be necessary. At a minimum, you could set the validity property immediately, not after the click. Then even when the value property is empty unset, form validation could at least detect that the field is will have a value.
,
Dec 7 2016
I don't think google looks at issues once the status is WontFix. But I think there are good arguments for reconsidering that stance. I've opened a new issue: https://bugs.chromium.org/p/chromium/issues/detail?id=669724 Please star the issue if you want Google to take notice. |
||
►
Sign in to add a comment |
||
Comment 1 by tkonch...@chromium.org
, Aug 11 2016Components: Privacy UI>Browser>Passwords
Labels: Needs-Feedback Restrict-View-Google