when Chrome autofills input[type="password"] the value & validity properties are not set until user clicks
Reported by
ben.p...@openreign.com,
Nov 30 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 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 password has been autofilled. What is the expected behavior? The input DOM object should have the autofilled value and the validity property on the DOM object should be equal to ValidityState.valid. What went wrong? Nothing happens until the user clicks on the page. Did this work before? No Does this work in other browsers? Yes Chrome version: 54.0.2840.99 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0 According to this issue (https://bugs.chromium.org/p/chromium/issues/detail?id=636425), this is a security feature. I think that issue was closed prematurely. This should be reconsidered. 1. Other browsers don't operate this way. Firefox and Edge set the value immediately. 2. There is perceived security, because this could stop a malicious site could open an iframe/popup to another domain and steal the user's password. However in practice this doesn't do much. If the user click in the frame or window, the password is given up. It would be better to disable password autofilling in iframes/windows opened across domains. 3. This complicates form validation and causes UI irregularities between browsers. Until the user clicks, there is no reliable way to know if the password field is empty. Many people have resorted to detecting the yellow autofill background color or take advantage of -webkit-autofill. 4. At least setting the validity property immediately, would provide a cross browser way to detect that the password has been autofilled without exposing the password.
,
Dec 2 2016
Unable to reproduce the issue on windows-7, Mac-10.11.6 and linux Ubuntu 14.04 using chrome stable version 55.0.2883.75 and latest canary 57.0.2938.0 with a sample form https://whytls.com/password.htm . Please find the attached screen-cast and could you please let us know if anything missed here to reproduce the issue. Thanks..
,
Dec 2 2016
It appears to me that you successfully reproduced the issue. Notice that when the form is first autofilled (around 19 seconds), the "current password field text" is empty. It's not until clicked on the page (around 21 seconds), that the change event fires and the value showed up. This behavior is part of Chrome. It's by design(https://bugs.chromium.org/p/chromium/issues/detail?id=636425). I just think the design should be reconsidered.
,
Dec 2 2016
If you inspect the page before clicking you can see that it's not just the change event that does change, but value is not set until you click. I've attached a video. You can see that the value property is initially not set even though the password box has been autofilled (0-5 seconds). Only after I clicked on the window (I clicked in the developer tools) and I move the mouse over the main page (around the 6 second mark) is the value property is set.
,
Dec 12 2016
Thank you for providing more feedback. Adding requester "sureshkumari@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 13 2016
Thanks for the report. While this is working as intended, I acknowledge that this is a controversial feature. The security team has been working on a proposal to abandon on-load filling completely (tracked by bug 568713 which is not public, I'm afraid). We prefer to invest into that change rather than investing into modifying the current one.
,
Jan 4 2017
Is there any way to track progress of this 568713. You say this issue won't be fixed, but will probably be fixed by fixing non-public bug 568713. What is the status of this? What if the proposal the security team is working on is rejected? will this issue be reopened?
,
Feb 24 2017
This is not complicated. Your browser is doing something that no other browser does, and in doing so is not adhering to standards. Just let us get the value of an autofilled password input like we can on literally any other browser.
,
Apr 21 2017
This issue also appears to happen for me Version 57.0.2987.133 (64-bit) Mac OSX 10.12.3 regards.
,
Apr 21 2017
Same here, Chrome version 57.0.2987.133 (64-bit), Mac OSX El Capital, 10.11.6
,
Aug 4 2017
Still the same for me on Linux, Chrome Version : Version 53.0.2785.143 (64-bit)
,
Sep 5 2017
This is pretty frustrating. I just want to disable the submit button by default, and re-enable it if the password is set. This bug stops anybody from doing this until the submit button is clicked. Frustrating.
,
Sep 7 2017
Issue 762361 has been merged into this issue. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ajha@chromium.org
, Nov 30 2016Labels: M-54