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

Issue 774390 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: Oct 18
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Unnecessary password is saved under Manage password section after removing it.

Reported by dchau...@etouch.net, Oct 13 2017

Issue description

Chrome Version: 63.0.3239.0 (Official Build)adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578} 32/64-bit.
OS: Windows (7,8,10),Linux (14.04 LTS),Mac(10.12.6).

What steps will reproduce the problem?
1. Launch chrome, login to fb.com with valid credentials, Save the password and logout from it.
2. Navigate to chrome://settings/passwords and remove the saved password.
3. Again go to Facebook tab and login with auto filled password.
4. Now again go to Manage password tab and observe.

Unnecessary password is saved under Manage password section.
Password should not save under Manage password section.

This is a non regression issue, seen from M-45 series.

Note: This issue is working fine in Firefox browser i.e password is not get saved after removing it.

Kindly review the attached screen-cast for reference.
 
Actual behavior.mp4
2.3 MB View Download
Status: Untriaged (was: Unconfirmed)
Untriaged it so that issue gets addressed.

Comment 2 by battre@chromium.org, Oct 13 2017

Cc: vabr@chromium.org
Components: -UI>Settings
Status: Available (was: Untriaged)
This is an interesting edge case: I think the problem is that information is cached in the PasswordFormManager that is owned by the UI.

Vaclav, is this part of the refactoring you are planning to do?

Comment 3 by vabr@chromium.org, Oct 16 2017

Cc: -vabr@chromium.org
Labels: -Pri-2 -M-63 Hotlist-Polish Pri-3
Thanks for the report and the screencast.
For everybody who did not see the screencast and is wondering, how there is a filled password in step 3 after removing it in step 2: the tab from step 3 has been open before step 2 and the password remained filled.

I'm not sure this will be fixed by any upcoming refactorings. We might just want to fix it directly, by better observing the password store changes.

Downgrading to priority 3 for being an edge-case.
Project Member

Comment 4 by sheriffbot@chromium.org, Oct 16

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Fixed (was: Untriaged)
I tried to reproduce with Chrome 72.0.3583.0 on Linux and the password is no longer re-added.

Sign in to add a comment