Issue metadata
Sign in to add a comment
|
auto fill does not work on usd253.powerschool.com
Reported by
paul.bea...@usd253.net,
Aug 3
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 10718.71.2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.87 Safari/537.36 Platform: 10718.71.2 (Official Build) beta-channel fizz-unibuild (fizz kench sion teemo wukong) Steps to reproduce the problem: 1. When signing in and telling to save my username and password 2. revisit website (username and password shows as being saved) 3. click on the username box or password box will not bring up auto fill option What is the expected behavior? Autofill should allow me to put in username and password that is saved What went wrong? Started happening on chromeos 68 beta, in chrome browser in windows it works fine. Did this work before? Yes 67 Chrome version: 68.0.3440.87 Channel: beta OS Version: 10718.71.2 Flash Version: Annoying but not the end of the world. ChromeOS Rocks!
,
Aug 7
updated to ChromeOS Dev channel and it now will work if I click on the password fill, clicking username field will not bring up auto fill options. Works fine from windows but not on ChromeOS
,
Aug 7
The issue does not happen in Windows Stable, Beta or Dev, only happens in Chrome OS 68 Beta on the site usd253.powerschool.com, other sites are auto populating well. As an additional comment, username is auto filling correctly well, the password is the field which does not work for this site in Chrome OS 68 Beta.
,
Aug 13
I'm not actually sure if that's the bug, I would say it looks more like fixed bug, which existed in previous versions, because this password field is - <input type="password" id="fieldPassword" name="pw" value="" size="39" autocomplete="new-password"> And autocomplete="new-password" should specifically forbid filling in old password from autofill, as far as I understand. But maybe I don't understand it correctly.
,
Aug 13
,
Aug 13
,
Aug 17
Thanks for the report and the enthusiastic attitude towards Chrome OS! vkhabarov@ identified correctly the root cause of this. The HTML annotation of the login form indeed tries to tell Chrome that this is a sign-up form instead of a sign-in one. Chrome cannot afford to ignore that in general, otherwise it would spam the real sign-up forms with useless characters. For this particular instance, the best fix would be to make the webmaster aware that the form mark-up needs fixing (guide at https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands). As a work-around in version 69 (freshly current beta), the user should be able to get both fields filled after clicking on the password field. This does not work in 68. In the long term, we are working on ways to distinguish fake "sign-up" forms from real ones, but that work is still ongoing. I'm sorry about this inconvenience. Because the workaround should start being available in beta now and there are long-term plans as well, I am now closing this report. Please let me know if there are further concerns, though. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by xiy...@chromium.org
, Aug 3