My code didn't touch the save/clear password logic.
I'll leave it to password manager forks to take a look.

Jan, didn't you work on this code? If not, we should find a different owner. Deleting the wrong password is bad.

I have worked on the code in the past, yes, but not recently. The recent Autofill Home changes should be unrelated. However, in the past we did have a bug in the UI where it looked like the wrong password was deleted. Once the page was refreshed, the expected passwords were shown.

Just to make sure this isn't the case here,  vineetha.sarma@ could you check if refreshing the page after deleting a password changes the list of visible passwords?

Update w.r.t Comment #3,

 As mentioned, checked by refreshing the page after deleting a password on Canary build #69.0.3488.0 for Win OS and observed that, the list of visible passwords does change(proper expected password is seen). 

 Additionally observed that ,if we try to login to gmail using the same deleted username/password again and save it to chrome then expected password is not seen properly under chrome://settings/passwords(i.e existing username/password entry gets repeated) unless the page is refreshed again.

Please refer attached screen cast.

Deleted: CanaryBehaviour.mp4 1.1 MB

	CanaryBehaviour.mp4 1.1 MB View Download

Thank you for confirming my suspicion. To re-iterate: We don't actually delete the wrong password, but in the settings UI it looks like we did, until the page is refreshed. This means this issue is similar to  https://crbug.com/786312  and the bugs merged into it. I had fixed the initial issue with r520200, which was part of M64. I will investigate which commit caused the regression and see what we can do to prevent this from happening in the future.

Suspecting r557337 as the culprit of this regression and adding aee@ as the owner of this bug.

Fix is in https://crrev.com/c/1138233.

Jan just brought this bug to my attention, thanks!

With this bug what happens is:

If the user has more than one credential for a given host:
- the first time a user deletes a credential from the list, it looks like the wrong credential gets deleted (under the hood, we actually delete the right one)
- if the user then "tries again", we will actually remove a wrong credential.

The latter is a really bad regression and warrants a stable block from my perspective.

Jan has a fix in flight. We should use it for the the upcoming stable release.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3f2d86f2d225af1bc3acf4f50c6887c65a5b2678

commit 3f2d86f2d225af1bc3acf4f50c6887c65a5b2678
Author: Jan Wilken Doerrie <jdoerrie@chromium.org>
Date: Mon Jul 16 23:21:48 2018

[Pwd List] Fix Display Of Passwords

This change fixes a bug when re-rendering the list of passwords after a
password store mutation. This bug could give the impression that a wrong
password was deleted.

Bug:  862119 
Cq-Include-Trybots: luci.chromium.try:closure_compilation
Change-Id: I13f42a18567f84e191e99a2beb6d00ee7e82e682
Reviewed-on: https://chromium-review.googlesource.com/1138233
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Commit-Queue: Jan Wilken Dörrie <jdoerrie@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575474}
[modify] https://crrev.com/3f2d86f2d225af1bc3acf4f50c6887c65a5b2678/chrome/browser/resources/settings/passwords_and_forms_page/passwords_section.js
[modify] https://crrev.com/3f2d86f2d225af1bc3acf4f50c6887c65a5b2678/chrome/test/data/webui/settings/passwords_and_autofill_fake_data.js
[modify] https://crrev.com/3f2d86f2d225af1bc3acf4f50c6887c65a5b2678/chrome/test/data/webui/settings/settings_passwords_section_browsertest.js

[Auto-generated comment by a script] We noticed that this issue is targeted for M-68; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-68 label, otherwise remove Merge-TBD label. Thanks.

Requesting merge of r575474 into M68.

This bug requires manual review: We are only 6 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Has this been verified in canary?

seems like this landed in https://chromium.googlesource.com/chromium/src/+/3f2d86f2d225af1bc3acf4f50c6887c65a5b2678

Approving merge to M68. Branch:3440

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b320e15788252f0df15fd3b24a1247fe2d739a46

commit b320e15788252f0df15fd3b24a1247fe2d739a46
Author: Jan Wilken Doerrie <jdoerrie@chromium.org>
Date: Tue Jul 17 18:32:15 2018

[Pwd List] Fix Display Of Passwords

This change fixes a bug when re-rendering the list of passwords after a
password store mutation. This bug could give the impression that a wrong
password was deleted.

Bug:  862119 
Cq-Include-Trybots: luci.chromium.try:closure_compilation
Change-Id: I13f42a18567f84e191e99a2beb6d00ee7e82e682
Reviewed-on: https://chromium-review.googlesource.com/1138233
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Commit-Queue: Jan Wilken Dörrie <jdoerrie@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#575474}(cherry picked from commit 3f2d86f2d225af1bc3acf4f50c6887c65a5b2678)
Reviewed-on: https://chromium-review.googlesource.com/1140853
Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#697}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/b320e15788252f0df15fd3b24a1247fe2d739a46/chrome/browser/resources/settings/passwords_and_forms_page/passwords_section.js
[modify] https://crrev.com/b320e15788252f0df15fd3b24a1247fe2d739a46/chrome/test/data/webui/settings/passwords_and_autofill_fake_data.js
[modify] https://crrev.com/b320e15788252f0df15fd3b24a1247fe2d739a46/chrome/test/data/webui/settings/settings_passwords_section_browsertest.js

Update:

Rechecked the above issue on Chrome Beta build #68.0.3440.68 and latest Canary build #69.0.3495.0, and observed that the above issue is fixed when only 2 username/password entries are present under chrome://settings/passwords but there are some additional observations/issues which are as following,

Senario 1 :
> Atleast 2 username/password entries should be present under chrome://settings/passwords, now remove the first entry and observe that correct entry is removed. 
> But now try to remove the last and only entry on the page and observe it does not get removed. Removing the last entry works only after refreshing the page. 

Scenario 2:
> Atleast 3 username/password entries should be present under chrome://settings/passwords, now remove the first entry and observe that correct entry is removed. 
> Now observe that 2 username/password entries are left, try removing the first username/password entry of the 2 remaining entries and observe that it appears that last entry gets deleted.
> Lastly just like in Scenario 1 , try to remove the last and only entry on the page and observe it does not get removed.Removing the last entry works only after refreshing the page. 

Please find attached screencast showing the Beta behaviour for both the above mentioned scenarios.

@jdoerrie/aee , kindly let us know if this needs to be filed as a separate issue.

Deleted: BetaBehaviour_Scenario1.mp4 728 KB

	BetaBehaviour_Scenario1.mp4 728 KB View Download

Deleted: BetaBehaviour_Scenario2.mp4 869 KB

	BetaBehaviour_Scenario2.mp4 869 KB View Download

I am  re-opening this bug, since per #20 it seems that it is not fully fixed. There are two candidate fixes

1) by jdoerrie: https://chromium-review.googlesource.com/c/chromium/src/+/1142146
2) by myself after chatting with jdoerrie: https://chromium-review.googlesource.com/c/chromium/src/+/1142486

I will proceed with the 2nd fix, assuming all tests are green, shortly.

Summarizing new findings below.

My proposed fix from previous comment does not actually work (thanks @scottchen for helping testing it). It breaks in the case where the user tries to delete a password while a search filter is present (the indices across UI and backend do not match).

So further investigated two options.
1) jdoerie's proposed fix at  https://chromium-review.googlesource.com/c/chromium/src/+/1142146
2) Fully reverting the usage of ListPropertyUpdateBehavior from passwords_section.js at https://chromium-review.googlesource.com/c/chromium/src/+/1142703.

Both of these solutions seem to fix the issue of deleting passwords. Approach 2 has a small caveat: It re-introduces a (minor) UI bug where deleting "never saved passwords" forces the entire page to scroll to the top.

Approach 1 seems to work fine (both fixes the issue and does not seem to regress anything I could notice). Upon further inspection of the underlying code at [1], it seems to me that including everything in the uidGetter (in this case the index that is sent to C++) is the right thing to do, when using that method. So I just approved that CL.

Overall, I think this regression would have been avoided with either a better C++/JS API that does not rely on matching indices across the two, or with more exhaustive testing.

[1] https://www.polymer-project.org/2.0/docs/api/namespaces/Polymer.ArraySplice

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c05442e00dbb8122eb1c17b62bb85c65940bd762

commit c05442e00dbb8122eb1c17b62bb85c65940bd762
Author: Jan Wilken Doerrie <jdoerrie@chromium.org>
Date: Thu Jul 19 08:23:34 2018

[Settings] Fix Deletion Of Passwords

This change augments the fix in https://crrev.com/c/1140853 to cover
other cases the first change missed.

Bug:  862119 
Cq-Include-Trybots: luci.chromium.try:closure_compilation
Change-Id: I59ca0f37aba90009b645b6ddb4b1413c5325f933
Reviewed-on: https://chromium-review.googlesource.com/1142146
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Commit-Queue: Jan Wilken Dörrie <jdoerrie@chromium.org>
Cr-Commit-Position: refs/heads/master@{#576419}
[modify] https://crrev.com/c05442e00dbb8122eb1c17b62bb85c65940bd762/chrome/browser/resources/settings/passwords_and_forms_page/passwords_section.js

r576419 got released in Version 69.0.3497.0 and is part of the latest Canary build. Testers, please verify that the issues shown in #c1, #c4 and #c20 are resolved now. Please also verify that the following issue is resolved as well:

Precondition: At least two passwords are saved, call them A and B.
1. Delete password A.
2. Refresh the page and undo the deletion via CTRL+Z (or CMD+Z on Mac).
3. Observe that the deleted password A gets restored.
4. Try to delete password B.
5. Observe that the password A gets deleted instead.

This issue used should be fixed in 69.0.3497.0 as well, and the correct entry should be deleted in step 5.

Update :
Rechecked the above issue on Windows(7,8,8.1,10)OS with latest Canary Chrome version #69.0.3497.0 and the issue is fixed.
The issues in comments: #1, #4 and #20 are fixed , also checked by executing the steps mentioned in comment #25 and the correct entry gets deleted in step 5.

Kindly refer the attached screen casts.

Deleted: CanaryBehaviour.mp4 480 KB

	CanaryBehaviour.mp4 480 KB View Download

Deleted: CanaryBehaviour2.mp4 481 KB

	CanaryBehaviour2.mp4 481 KB View Download

Thank you for verifying the fix! Requesting the merge of r576419 into M68 as well.

This bug requires manual review: We are only 3 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7d210b09a3e0418803ed72eb781fdf4b8147a9f5

commit 7d210b09a3e0418803ed72eb781fdf4b8147a9f5
Author: Jan Wilken Doerrie <jdoerrie@chromium.org>
Date: Fri Jul 20 17:11:47 2018

[Settings] Fix Deletion Of Passwords

This change augments the fix in https://crrev.com/c/1140853 to cover
other cases the first change missed.

Bug:  862119 
Cq-Include-Trybots: luci.chromium.try:closure_compilation
Change-Id: I59ca0f37aba90009b645b6ddb4b1413c5325f933
Reviewed-on: https://chromium-review.googlesource.com/1142146
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Commit-Queue: Jan Wilken Dörrie <jdoerrie@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#576419}(cherry picked from commit c05442e00dbb8122eb1c17b62bb85c65940bd762)
Reviewed-on: https://chromium-review.googlesource.com/1145500
Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#725}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/7d210b09a3e0418803ed72eb781fdf4b8147a9f5/chrome/browser/resources/settings/passwords_and_forms_page/passwords_section.js

Update :

Rechecked the above issue on Windows(7,8,8.1,10)OS using Stable build #68.0.3440.75 and the issue is fixed.
Kindly refer the attached screen cast.

Deleted: StableBehaviour.mp4 594 KB

	StableBehaviour.mp4 594 KB View Download