Able to reproduce this issue on reported version 65.0.3325.162, on latest beta 66.0.3359.45 and on latest canary 67.0.3377.0 using Mac 10.13.3, Windows 10 and Ubuntu 14.04.

This issue is seen from introduction of save password bubble in M-64. Hence considering  this issue as Non-Regression and marking Untriaged.

Thanks!

What is the site page?

Can you try to use the manual flow?
- Type your credentials on the sign-in page but don't click "Sign in".
- open the password bubble via the key icon in the omnibox.
- Is it the update bubble? Is the captured password correct?

As a second experiment please open chrome://password-manager-internals/ in a tab. Then navigate to the site and login there. Paste the log from the password manager here.

Mac triage: assigning directly to vasilii@ for followup - it sounds like TE has a working repro.

I can reproduce the issue

Please answer the questions in comment #3.

Website:
https://www.hdfcbank.com/nri_banking/home.htm
Click on netbanking, Login, Continue to netbanking

I clicked on Key icon.  Password is not visible, only a bunch of ****

2nd experiment opened chrome://password-manager-internals/
Getting message below. 
Captured password manager logs are listed below. Logs are cleared and no longer captured when all password-manager-internals pages are closed.

The manual fallback works fine. I clicked the eye icon and the password is exactly what I typed.

pbekal@ could you open chrome://password-manager-internals/ and then in the second tab login to the bank? The log from chrome://password-manager-internals/ shouldn't be empty.

The password is not the same when google ask for it update.  See screen
shots.

Logs attached

No screeshot/logs attached. Please attach via the site crbug.com

Password Issue Screen shots.
The logs have account information so will not be able to attach.
Let me know if you need to see any section of the logs.

Deleted: password issue.docx 27.0 KB

password issue.docx 27.0 KB Download

It shouldn't have both the username and the password. You can replace the account information with xxxx. The fact that some private information ended up in the log is also a bug that I'd like to investigate.

Uploading log.

Deleted: password issue logs.docx 34.5 KB

password issue logs.docx 34.5 KB Download

Here is what happening.
The login form is in the iframe and is has target="_top" parameter.
- The user is typing the password. PasswordManager gets the signal and saves |provisional_save_manager_| (correct).
- The user clicks "Login". The page JS replaces the password with a hash. Then the form is submitted. We have a protection against it but...
- The iFrame with the form doesn't see the submission. Instead the top frame is notified and it has no idea about the typed value. PasswordManager::OnPasswordFormSubmitted is called and a valid |provisional_save_manager_| is replaced with the hashed value (wrong)
- Still it doesn't trigger the bubble yet.
- The frame with the form is destroyed and PasswordAutofillAgent::OnFrameDetached calls PasswordManager::OnSameDocumentNavigation with the correct password (correct).
- Unthinkable happens. PasswordManager::OnPasswordFormSubmittedNoChecks must save |provisional_save_manager_| and it fails because we don't find PasswordFormManager handling the form. (wrong)
- OnSameDocumentNavigation proceeds. OnLoginSuccessful() is called with the current |provisional_save_manager_|. It has the hashed value and that is what we show in the bubble.

Can we get a fix for this ?

I'm working on the fix. It's nontrivial so I have to change the tests first.

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

commit 63317dd5fc2a3310dca673aafb45ee10511770bf
Author: Vasilii Sukhanov <vasilii@chromium.org>
Date: Thu May 24 14:12:14 2018

Password Manager: don't drop the information about existing forms on submit.

PasswordManager::OnPasswordFormSubmitted is called when a form is submitted. It doesn't mean that PasswordManager should forget about everything it saw before.
Despite the data is provisionally saved, it's not time to show the bubble yet. Therefore, there may be another event coming that would trigger the bubble.

For the concrete bug the consequences are the following:
- the hashed password is still provisionally saved via OnPasswordFormSubmitted(). It's correct because we don't know that it's hashed. Ideally, we should protect against JS modifications in PasswordManager. Currently we do it in PasswordAutofillAgent::OnWillSubmitForm.
- PasswordAutofillAgent::OnFrameDetached() later triggers the successful login. The data provided is actually correct and propagated to the bubble.

Bug:  823562 
Change-Id: Ib23f2d4188e57f04d766997367c69f8613dacb17
Reviewed-on: https://chromium-review.googlesource.com/1044605
Commit-Queue: Vasilii Sukhanov <vasilii@chromium.org>
Reviewed-by: Vadym Doroshenko <dvadym@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561493}
[modify] https://crrev.com/63317dd5fc2a3310dca673aafb45ee10511770bf/chrome/browser/password_manager/password_manager_browsertest.cc
[add] https://crrev.com/63317dd5fc2a3310dca673aafb45ee10511770bf/chrome/test/data/password/password_form_with_hash.html
[modify] https://crrev.com/63317dd5fc2a3310dca673aafb45ee10511770bf/components/password_manager/core/browser/password_manager.cc
[modify] https://crrev.com/63317dd5fc2a3310dca673aafb45ee10511770bf/components/password_manager/core/browser/password_manager_unittest.cc