Chrome is showing old saved password while signing in with different email id.
Reported by
aiman.an...@etouch.net,
Aug 23 2017
|
|||||||||||
Issue descriptionChrome Version : 62.0.3194.0 (Official Build) c14400a94cb4f43e0e9b02e59e93cf5a082c6408-refs/heads/master@{#496533}(64-bit) OS: Windows (7,8,10),Linux (14.04 LTS),Mac OS X(10.11.6,10.12.3). Steps to reproduce: 1. Launch chrome, sign in to Gmail with valid credentials and save password. 2. On gmail page, click on profile icon and select Add Account. 3. On sign page, enter other email id and click on next option. 4. Observe. (Kindly check the attached screen-cast). Actual Result: Chrome is showing old saved password while signing in with different email id. Expected Result:Chrome should not show old saved password while signing in with different email id. Note: This is an Non-Regression Issue seen from M-45
,
Aug 23 2017
As this being a Non-Regression issue, changing the status to Untriaged so that the issue would get addressed. Thank You!
,
Oct 18 2017
Thanks for the report. I could reproduce it, it also works when one signs out and tries to sign into a different google account. This is what happens: (1) accounts.google.com loads the page with the visible username field; however, it also contains an invisible password field (2) Chrome fills the visible username and the invisible password on load, with the (only) stored account (3) the user changes the username, the hidden password field remains filled (4) the user submits the new username, Chrome detects that as a password submission and a successful login, hence it offers to save the password (5) accounts.google.com change the form to make username invisible and password visible; the password field stays filled (although for some reason not with the yellow background) It's generally useful that after editing the filled username, the password stays filled. This allows username correction. But perhaps Chrome could avoid filling invisible password fields, and attempt to fill them once they become visible? Also, Chrome should not regard the submit of the username and display of the password form as a successful login. That would get rid of the confusing prompt for saving. I'm Cc-ing dvadym@ who had fixed issues on accounts.google.com in the past and could have interesting opinions. Also Cc-ing battre@ in case he knows about somebody looking into successful submit detection soon (I'm afraid I forgot the detailed team plans and could not find the draft document). Linking to bug 770184 because potentially, we could stop filling invisible password fields (if we detect their visibility and are able to fill on becoming visible). Also linking to bug 775899 for the login success detection.
,
Oct 19 2017
Issue 752045 has been merged into this issue.
,
Oct 23 2017
,
Oct 23 2017
,
Jan 29 2018
Vadym could you take a look as you already fixed a couple gmail bugs?
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/28d0c4aaba2aedddacd384df63f111f0938cbf42 commit 28d0c4aaba2aedddacd384df63f111f0938cbf42 Author: Vadym Doroshenko <dvadym@chromium.org> Date: Wed Aug 29 14:51:16 2018 Fix false saving positives on accounts.google.com. In the following case false positive on accounts.google.com happens: 1.Suppose that the user has 2 Gaia credentials (with usernames and passwords u1/p1 and u2/p2). Let u1 be saved in Password Manager. 2.The user go to accounts.google.com, u1/p1 are autofilled by CPM (a username field is visible, a password field is invisible). 3.The user is typing u2 in the username field and is clicking next button. 4.At that moment the page removes password form from the DOM and Password Manager incorrectly thinks that it was successful submission with u2/p1 Video is on bug 764663 (actual_bubble). This CL fixes this by ignoring accounts.google.com forms with submitted type DOM_MUTATION_AFTER_XHR, which means that the form disappeared from the DOM, without any visible submission. Similar issues might be on different sites, this CL fixes only accounts.google.com, because 1.A general solution is unlikely without more complex changes and server-side support. 2.accounts.google.com is crucial for Chrome, in particular because it serves the Chrome sign-in page. Bug: 758155 , 764663 Change-Id: I44f9878673bf8f419c49f63220335f6c0f26a6e4 Reviewed-on: https://chromium-review.googlesource.com/1194011 Commit-Queue: Vadym Doroshenko <dvadym@chromium.org> Reviewed-by: Vaclav Brozek <vabr@chromium.org> Cr-Commit-Position: refs/heads/master@{#587115} [modify] https://crrev.com/28d0c4aaba2aedddacd384df63f111f0938cbf42/components/password_manager/core/browser/password_manager.cc [modify] https://crrev.com/28d0c4aaba2aedddacd384df63f111f0938cbf42/components/password_manager/core/browser/password_manager_unittest.cc
,
Aug 29
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/64009bd0adf132b24e4075a1295ea676449af0ac commit 64009bd0adf132b24e4075a1295ea676449af0ac Author: Vadym Doroshenko <dvadym@chromium.org> Date: Thu Aug 30 08:27:21 2018 Revert "Fix false saving positives on accounts.google.com." This reverts commit 28d0c4aaba2aedddacd384df63f111f0938cbf42. Reason for revert: this CL breaks saving passwords on accounts.google.com with second factor enabled. Original change's description: > Fix false saving positives on accounts.google.com. > > In the following case false positive on accounts.google.com happens: > > 1.Suppose that the user has 2 Gaia credentials (with usernames and passwords > u1/p1 and u2/p2). Let u1 be saved in Password Manager. > > 2.The user go to accounts.google.com, u1/p1 are autofilled by CPM (a username > field is visible, a password field is invisible). > > 3.The user is typing u2 in the username field and is clicking next button. > > 4.At that moment the page removes password form from the DOM and Password > Manager incorrectly thinks that it was successful submission with u2/p1 > > Video is on bug 764663 (actual_bubble). > > This CL fixes this by ignoring accounts.google.com forms with submitted > type DOM_MUTATION_AFTER_XHR, which means that the form disappeared from the > DOM, without any visible submission. > > Similar issues might be on different sites, this CL fixes only > accounts.google.com, because > 1.A general solution is unlikely without more complex changes and server-side > support. > 2.accounts.google.com is crucial for Chrome, in particular because it serves > the Chrome sign-in page. > > > Bug: 758155 , 764663 > > Change-Id: I44f9878673bf8f419c49f63220335f6c0f26a6e4 > Reviewed-on: https://chromium-review.googlesource.com/1194011 > Commit-Queue: Vadym Doroshenko <dvadym@chromium.org> > Reviewed-by: Vaclav Brozek <vabr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#587115} TBR=vabr@chromium.org,dvadym@chromium.org Change-Id: Idd261e61ca9c7653a1fa72cb175db4afe5ee91fb No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 758155 , 764663 Reviewed-on: https://chromium-review.googlesource.com/1195511 Reviewed-by: Vadym Doroshenko <dvadym@chromium.org> Commit-Queue: Vadym Doroshenko <dvadym@chromium.org> Cr-Commit-Position: refs/heads/master@{#587482} [modify] https://crrev.com/64009bd0adf132b24e4075a1295ea676449af0ac/components/password_manager/core/browser/password_manager.cc [modify] https://crrev.com/64009bd0adf132b24e4075a1295ea676449af0ac/components/password_manager/core/browser/password_manager_unittest.cc
,
Sep 5
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/02f40d918c55c943f87d42cb805fd667f7e2fc7d commit 02f40d918c55c943f87d42cb805fd667f7e2fc7d Author: Vadym Doroshenko <dvadym@chromium.org> Date: Wed Sep 05 17:15:48 2018 Fix false saving positives on accounts.google.com. In the following case false positive on accounts.google.com happens: 1.Suppose that the user has 2 Gaia credentials (with usernames and passwords u1/p1 and u2/p2). Let u1 be saved in Password Manager. 2.The user go to accounts.google.com, u1/p1 are autofilled by CPM (a username field is visible, a password field is invisible). 3.The user is typing u2 in the username field and is clicking next button. 4.At that moment the page removes password form from the DOM and Password Manager incorrectly thinks that it was successful submission with u2/p1 Video is on bug 764663 (actual_bubble). This CL fixes this by ignoring for saving accounts.google.com forms without a visible password field. Similar issues might be on different sites, this CL fixes only accounts.google.com, because 1.A general solution is unlikely without more complex changes and server-side support. 2.accounts.google.com is crucial for Chrome, in particular because it serves the Chrome sign-in page. Bug: 758155 , 764663 , 880876 Change-Id: I57bbe94ea0a6d101c6a5a33cf354b42f0d0353fc Reviewed-on: https://chromium-review.googlesource.com/1206476 Commit-Queue: Vadym Doroshenko <dvadym@chromium.org> Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org> Cr-Commit-Position: refs/heads/master@{#588907} [modify] https://crrev.com/02f40d918c55c943f87d42cb805fd667f7e2fc7d/components/password_manager/core/browser/password_manager.cc [modify] https://crrev.com/02f40d918c55c943f87d42cb805fd667f7e2fc7d/components/password_manager/core/browser/password_manager_unittest.cc
,
Sep 12
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c40ebd5dbd53b4acdb954d1c989ca4ed4f03953e commit c40ebd5dbd53b4acdb954d1c989ca4ed4f03953e Author: Vadym Doroshenko <dvadym@chromium.org> Date: Wed Sep 12 10:59:55 2018 Fix false saving positives on accounts.google.com. In the following case false positive on accounts.google.com happens: 1.Suppose that the user has 2 Gaia credentials (with usernames and passwords u1/p1 and u2/p2). Let u1 be saved in Password Manager. 2.The user go to accounts.google.com, u1/p1 are autofilled by CPM (a username field is visible, a password field is invisible). 3.The user is typing u2 in the username field and is clicking next button. 4.At that moment the page removes password form from the DOM and Password Manager incorrectly thinks that it was successful submission with u2/p1 Video is on bug 764663 (actual_bubble). This CL fixes this by ignoring for saving accounts.google.com forms without a visible password field. Similar issues might be on different sites, this CL fixes only accounts.google.com, because 1.A general solution is unlikely without more complex changes and server-side support. 2.accounts.google.com is crucial for Chrome, in particular because it serves the Chrome sign-in page. Bug: 758155 , 764663 , 880876 TBR=dvadym@chromium.org (cherry picked from commit 02f40d918c55c943f87d42cb805fd667f7e2fc7d) Change-Id: I57bbe94ea0a6d101c6a5a33cf354b42f0d0353fc Reviewed-on: https://chromium-review.googlesource.com/1206476 Commit-Queue: Vadym Doroshenko <dvadym@chromium.org> Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#588907} Reviewed-on: https://chromium-review.googlesource.com/1221255 Reviewed-by: Vadym Doroshenko <dvadym@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#318} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811} [modify] https://crrev.com/c40ebd5dbd53b4acdb954d1c989ca4ed4f03953e/components/password_manager/core/browser/password_manager.cc [modify] https://crrev.com/c40ebd5dbd53b4acdb954d1c989ca4ed4f03953e/components/password_manager/core/browser/password_manager_unittest.cc |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by aiman.an...@etouch.net
, Aug 23 2017