This problem doesn't reproduce for me.

I verified on Chrome 51.0.2683, Android 6.0.1

Here are my repro steps:
- Account T1 has one saved password. I sign in with this account, navigate to website, ensure that password is populated.
- Account T2 doesn't have saved passwords. I sign in with T2, select "Keep existing data separate", navigated to the same website and ensured that password is not populated.

I checked about:sync => "Sync Node Browser" to ensure that password is not synced in T2.
I also verified on passwords.google.com that T2 didn't get password from T1.

caon@: could you describe how you check passwords in step 3?

I checked passwords under Settings > Smart Lock for Passwords and saw the passwords from the other account

Steven,
Rachel mentioned that Smart Lock shows passwords for all accounts configured on device. That would explain behavior observed in this bug. Could you confirm that that's the case?

No, it's only Smart Lock for native apps that will show info for all accounts on the device, I'm not sure about what should happen for Chrome. Ask Sabine?

Ok, one more repro:
When I open android settings -> Google -> "Smart Lock for Passwords" it shows "Saved passwords" section with link to "Google Account". No passwords are shown on this screen. At the top of the screen I can select account that these settings apply to.
When I tap on the link it opens http://account.google.com in chrome and offers me to sign in. The account here doesn't necessarily match with account on "Smart Lock for Passwords" screen. When I sign in chrome gets redirected to passwords.google.com where it shows correct list of passwords. My current user name is displayed in top right corner. I can switch between T1 and T2 there. 

caon@: Is what you see similar to what I described?

Yes I saw same things.  However I don't usually test those parts so I'm not sure what the expected behaviors are.

caon, when you visit passwords.google.com (linked from settings -> smart lock for passwords), please let us know what account you're using. This is an authenticated web site and is usabled with all accounts on the device, and does not necessarily load with under the syncing account's credentials. 

I agree that this is confusing, but unless you see T1's password when signed in to the chrome content area as T2, I don't think this is a bug.

My original report of seeing T1 passwords was logged in to Chrome as T2, and that "settings -> smart lock for passwords" was from Chrome settings (not android settings), therefore I was seeing T1's password when signed in to chrome as T2, see screenshot

Deleted: Screenshot_20160318-155105.png 85.3 KB

	Screenshot_20160318-155105.png 85.3 KB View Download

I get that, but when you were looking at the password itself you were on a website. What account was signed into the website?

I managed to repro it on my device. "Smart Lock for Passwords" item is called "Save passwords" on my device for some reason.
I'll get more accurate repro steps and investigate the reason.

I'm just reproducing now and I'm signed into passwords.google.com with sync893@gmail.com, I can see some passwords from accounts neilcao0592@hotmail.com and neilcao0593@gmail.com

Deleted: Screenshot_20160318-162836 (1).png 213 KB

	Screenshot_20160318-162836 (1).png 213 KB View Download

Vasilii, could you take a look as well?

peconn@: Could you check if this bug is related to you recent change? http://crrev.com/1754903002

My guess so far is that bug caused by http://crrev.com/1739053002 where period for removing data was changed from Unbounded to value read from preferences, default value is one hour.

msramek@, could you take a look?

pavely@: Correct. I made the deletions on Android respect the time selection preference, similarly as we do on Desktop. At the same time, the sign-in flow stopped using the dialog, and relied on the deletion always being unbounded.

It would have been caught by manual testing if we haven't done our changes at approximately the same time :-( The moral of the story is to better coordinate even if it seems that our launches are just tangentially related.

Here is the fix: https://codereview.chromium.org/1823593002/, I'll get it landed ASAP.

In the meantime, peconn@, do you have ideas how to test in the sign-in code that everything is deleted between the sign-out and sign-in? Basically, we need to add fake history / password / etc. entries with very old timestamps, for which we need testing instances of the associated services, and we don't have that on Android. Currently, most of the Java code relies on everything being tested on the native side, and then just correctly calling the native side. I'll try to pipe TestPasswordStore to PrefServiceBridge, so we can test at least that.

Landing the change now so that I can merge it quickly. I'll add a bunch of tests for both the CBD dialog and the sign-in flow this week. Sorry for the trouble :-/

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

commit 5f5b82dc246c721ceb634983719494519694e57b
Author: msramek <msramek@chromium.org>
Date: Mon Mar 21 17:27:19 2016

Pass the time parameter to PrefServiceBridge.clearBrowsingData() explicitly.

The browsing data deletion on Android relied on the prefs::kDeleteTimePeriod
to determine the time period selection, similarly as we do on Desktop.

However, this is incorrect with respect to callsites in ChromeApplication and
ConfirmImportSyncDataDialog, that rely on the time period used being EVERYTHING.

Pass the time time period parameter explicitly, so that different callsites
can specify which time period to use.

BUG= 595876 

Review URL: https://codereview.chromium.org/1823593002

Cr-Commit-Position: refs/heads/master@{#382317}

[modify] https://crrev.com/5f5b82dc246c721ceb634983719494519694e57b/chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java
[modify] https://crrev.com/5f5b82dc246c721ceb634983719494519694e57b/chrome/android/java/src/org/chromium/chrome/browser/preferences/PrefServiceBridge.java
[modify] https://crrev.com/5f5b82dc246c721ceb634983719494519694e57b/chrome/android/java/src/org/chromium/chrome/browser/preferences/privacy/ClearBrowsingDataPreferences.java
[modify] https://crrev.com/5f5b82dc246c721ceb634983719494519694e57b/chrome/android/java/src/org/chromium/chrome/browser/sync/ui/ConfirmImportSyncDataDialog.java
[modify] https://crrev.com/5f5b82dc246c721ceb634983719494519694e57b/chrome/browser/android/preferences/pref_service_bridge.cc

I did another round of testing to verify that with this patch, passwords are deleted when the user choses not to import data during the account switch (locally, as the user is not signed in at the time).

This patch hasn't passed the Dev release yet, but given the severity, and the fact that the CL is small and it's easy to visually check its correctness, I'm asking for merge permission now. I'll wait for the next Canary/Dev release and retest there again.

Your change meets the bar and is auto-approved for M50 (branch: 2661)

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

commit 92a45e7a6ec4eaf2e37e7cc76aeadd6789a86b76
Author: Martin Sramek <msramek@chromium.org>
Date: Tue Mar 22 16:55:47 2016

Pass the time parameter to PrefServiceBridge.clearBrowsingData() explicitly.

The browsing data deletion on Android relied on the prefs::kDeleteTimePeriod
to determine the time period selection, similarly as we do on Desktop.

However, this is incorrect with respect to callsites in ChromeApplication and
ConfirmImportSyncDataDialog, that rely on the time period used being EVERYTHING.

Pass the time time period parameter explicitly, so that different callsites
can specify which time period to use.

BUG= 595876 

Review URL: https://codereview.chromium.org/1823593002

Cr-Commit-Position: refs/heads/master@{#382317}
(cherry picked from commit 5f5b82dc246c721ceb634983719494519694e57b)

Review URL: https://codereview.chromium.org/1823073004 .

Cr-Commit-Position: refs/branch-heads/2661@{#344}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/92a45e7a6ec4eaf2e37e7cc76aeadd6789a86b76/chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java
[modify] https://crrev.com/92a45e7a6ec4eaf2e37e7cc76aeadd6789a86b76/chrome/android/java/src/org/chromium/chrome/browser/preferences/PrefServiceBridge.java
[modify] https://crrev.com/92a45e7a6ec4eaf2e37e7cc76aeadd6789a86b76/chrome/android/java/src/org/chromium/chrome/browser/preferences/privacy/ClearBrowsingDataPreferences.java
[modify] https://crrev.com/92a45e7a6ec4eaf2e37e7cc76aeadd6789a86b76/chrome/android/java/src/org/chromium/chrome/browser/sync/ui/ConfirmImportSyncDataDialog.java
[modify] https://crrev.com/92a45e7a6ec4eaf2e37e7cc76aeadd6789a86b76/chrome/browser/android/preferences/pref_service_bridge.cc

The fix made it to Beta today. I did several rounds of testing, and it behaves as expected - passwords are imported iff the user chooses to do so.

This has been fixed a while back. Verified in 53.0.2783.0 and can confirm that passwords are not imported to the second account.