New issue
Advanced search Search tips

Issue 792416 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Autofill input with type='password' will trigger to autofill another input type='tel' in the same form

Reported by viperkod...@gmail.com, Dec 6 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.97 Safari/537.36 Vivaldi/1.94.1008.34

Steps to reproduce the problem:
1. Login to web page with email and password using form with input fields with types 'text' and 'password' respectively

2. Save email/password pair to SmartLock

3. Open another form on the web page after saving operation with 3 inputs with types: 
1) 'email' (disabled one, because of the parameter 'disabled' of the input tag)
2) 'tel' (it is empty by default, because it's our first login)
3) 'password'

4. Focus on input with type 'password' and hover over saved email

What is the expected behavior?
Password and only the password would be retrieved from SmartLock

What went wrong?
Empty input with 'tel' type type will also get email adress instead of nothing 

Did this work before? N/A 

Chrome version: 62.0.3202.97  Channel: stable
OS Version: 10.0
Flash Version: 

autocomplete='tel' or autocomplete='off' parameters of the <input> tag with type='tel' are not quite useful (they doesn't work)

I think there is a problem in how browser is actually interpret type='tel', for some reasons it cannot interpret type='tel' and use type='text' instead according to https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill
 
And yes, there is one more thing to be mentioned. 

If I'll use browser console (case where we haven't any email/password pairs in SmartLock) and I'll change type of the login's page input from type='text' to type='email' and so on using "Steps to reproduce" - it'll also has no effect.
Components: -Blink UI>Browser>Autofill

Comment 3 by y...@yoav.ws, Feb 1 2018

Cc: battre@chromium.org
It seems like this issue is applicable to other input types, where the field preceding the password field is assumed to be the username field and autofilled as such, even when `autocomplete=off` is present.

Comment 4 by ma...@chromium.org, May 22 2018

Status: Untriaged (was: Unconfirmed)

Sign in to add a comment