New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 798709 link

Starred by 19 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Inability to disable all kinds of autocompletion on a text field

Reported by a...@codeart.us, Jan 3 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Steps to reproduce the problem:
1. Add autocomplete="off"
2. Observe autocompletion still happens

What is the expected behavior?
Autocompletion should be disabled with autocomplete="off", like other browsers do this. Not with "false" or any other hacks/tricks, like "new-password". This is not a password field.

What went wrong?
We do use libraries that replace regular <select> with a customizable drop-down allowing users to search and use AJAX to dynamically load list options (useful for large lists). The library provides a text field where users can type a query, see the screenshot attached – a double drop-down displayed with no way for us to disable autocompletion for this field.

The content of this field is not submitted to the web server, the field doesn't even have a name attribute, so forcing autocompletion on such fields is nonsense.

Did this work before? Yes 

Does this work in other browsers? Yes

Chrome version: 63.0.3239.84  Channel: n/a
OS Version: OS X 10.13.2
Flash Version:
 
Screen Shot 2017-12-27 at 9.31.53 AM.png
67.5 KB View Download
Labels: Needs-Triage-M63 Needs-Bisect
Thanks for filing the issue.

@Reporter:
Could you please share a sample test File/Web URL which helps us in triage the issue. Can you please provide the screencast of the excepted behaviour of the issue reporter which helps us in better understanding it. Any further inputs from your end may help us.

Thanks!
Cc: viswatej...@techmahindra.com sc00335...@techmahindra.com
Labels: Needs-Feedback Triaged-ET

Comment 4 by a...@codeart.us, Jan 4 2018

Hi, I only have that screenshot from one of our users. So far I can't reproduce this on my end. Attached screenshot displays the expected behavior. Will ask for the exact browser version.
Screen shot 2018-01-04 at 16.02.09.png
168 KB View Download
Project Member

Comment 5 by sheriffbot@chromium.org, Jan 4 2018

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Components: Blink>Forms>Text
[mac bug triage]
As per comment#4 from the reporter adding the Needs-Feedback label
Labels: Needs-Feedback

Comment 9 by tkent@chromium.org, Jan 8 2018

Components: -Blink>Forms>Text UI>Browser>Autofill
I can reproduce this in 63.0.3239.132, running on Arch Linux

Comment 11 by mloc...@gmail.com, Feb 21 2018

This is strictly related to https://bugs.chromium.org/p/chromium/issues/detail?id=587466 (where many developers spent a lot of time describing why Chome should respect the autocomplete=off attribute, uselessly)
Images speak louder than words (hopefully). 
This is why developers (and Google itself) need autocomplete="off" to be respected by browsers:
autocompletegooglemaps.png
39.9 KB View Download
Labels: OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Mac triage: marking for Autofill triage and widening OS flags.
Cc: est...@chromium.org
Owner: ma...@chromium.org
Status: Assigned (was: Untriaged)
Mac triage: to mathp@ and estade@ directly for autofill triage.

Sign in to add a comment