Regression: [Password] Saved password entry doesn't get encrypted after removing the password.
Reported by
dchau...@etouch.net,
Oct 24
|
|||
Issue descriptionChrome Version: 72.0.3590.0 (Official Build) Revision ec242826af28a2b3c3b47390ab6141cfe26fe9e7-refs/branch-heads/3590@{#1} (32/64-bit) OS: Windows (7, 8, 8.1, 10), Mac (10.13.1, 10.13.6, 10.14.1) and Linux (14.04 LTS) Pre-condition: At-least 2-3 entry of password must be saved under 'Saved Password' section on chrome://settings/passwords page. What steps will reproduce the problem? 1. Launch Chrome and navigate to chrome://settings/passwords page. 2. decrypt all the password by clicking on eye (show password) icon. 3. Now remove the any password entry from 'more actions' list and observe. Actual: Saved password entry doesn't get encrypted after removing the password. Expected: All the saved password entry should get encrypted after removing the password. This is a regression issue, broken in M-72 series, below is manual regression range: Good build: 72.0.3583.0 (Revision: 600164) Bad build: 72.0.3584.0 (Revision: 600616) You are probably looking for a change made after 600332 (known good), but no later than 600339 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/9ac699ea5097cbedcd35da291ec56ce06d0a7b43..741374210d27cff7a2c2aa0bbbc67b27d493536c Suspecting: https://chromium.googlesource.com/chromium/src/+/e5b3b7b382787d750c0bee81feef48117b65caff @jdoerrie: 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. NOTE: 1. Provided suspect through 'Chromium bisect' script because unable to perform bisect using 'per-revision' bisect script. 2. Tried performing 'per revision' bisect on multiple Windows and Mac machines but unable to perform the same since getting "RuntimeError: We don't have enough builds to bisect." error. Kindly review the attached screen-cast for reference. Thank you.
,
Oct 24
I'm considering this a feature, not a bug and am inclined to mark this as WontFix. The reason is the following: Prior to r600335 deleting a password would not hide all the passwords, but just the ones after the deleted one. That is, assuming you have 3 passwords and they're all shown, deleting the 2nd one would hide the 3rd password, but continue to show the 1st one. This is not obvious from the videos, as here the first password was deleted, but deleting any other password would showcase this effect. The described behavior is inconsistent and confusing, so I fixed it in r600335. Consistency is achieved by either always hiding all passwords after a deletion, or not hiding any previously shown password. I went with the latter option, as I considered this to be more natural. It would be surprising to me, if deleting a password at the top of the list would hide passwords at the bottom, and vice-versa. +maxwalker@, do you have share my opinion around the behavior introduced by r600335?
,
Oct 24
|
|||
►
Sign in to add a comment |
|||
Comment 1 by rbasuvula@chromium.org
, Oct 24