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

Issue 773246 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression:Password gets automatically save in username field.

Reported by shruti.j...@etouch.net, Oct 10 2017

Issue description

Chrome Version: 63.0.3236.0 2fa96eead8c5eea003b5b7fb4f9262b3d136d76b-refs/heads/master@{#507286}(32/64Bit)

OS: Win(7,8,10), Mac(10.12.6) and Linux(14.04 LTS).

Test URL: https://www.gmail.com

Steps to reproduce:
1.Launch chrome ,navigate to above url.
2.Log in with valid credentials and go to change password from settings of gmail.
3.Two fields appears first is New Password and second is Confirm Password.
4.Do not enter same value in both the fields click on change password ,one message appears 'password does not match'.
5.Now click on Eye icon in New Password  field and enter same above password in confirm password field click on change password.
6.Observe password bubble and also go to manage password and see in username field password gets  automatically saved.


Actual Result: Password gets automatically save in username field in save password bubble.
Expected Result:Password should not  get automatically save in username field in save password bubble.
This is regression issue broken in ‘M-62’ and below per-revision bisect result

Using the per-revision bisect providing the bisect results,
Good Build: 62.0.3189.0(Revision:495411).
Bad Build: 62.0.3190.0(Revision:495757).

You are probably looking for a change made after 495497 (known good), but no later than 495498 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/88d4be6681463c9d7edaf5aee85b0ed79d650f22..eb43f526b0c14050ce834025dc1021e552e6039a


Suspect:https://chromium.googlesource.com/chromium/src/+/eb43f526b0c14050ce834025dc1021e552e6039a

@cfroussios:Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner





 
actualpwd.mp4
3.4 MB View Download
expectededpwd.mp4
3.9 MB View Download
Labels: ReleaseBlock-Stable
Tagging with blocker label, please undo if not the case.

Thanks.!
Labels: -M-63 M-62
Cc: dvadym@chromium.org kolos@chromium.org
I was able to verify that the bubble proposes the old (rejected) value of the confirm-password field.
Labels: -ReleaseBlock-Stable
Status: WontFix (was: Assigned)
After a discussion with Vadym, we believe that this feature is working as intended.

Before my patch, the Password Manager would detect no submission, which is a bug. Now, we correctly see the submission, as fixed by my patch.

The fact that a revealed password is interpreted as a username is an existing issue. It is caused by the fact that, in order for the password value to be revealed, the password field is no longer of type password in the dom.

Sign in to add a comment