Able to reproduce the issue on Mac 10.12.6 and Win-10 using chrome stable version #62.0.3202.94 and latest canary #64.0.3268.0.
Issue is not seen in OS-Linux.
This is a non-regression issue as it is observed from M62 old builds. 
Note: From M61 and older builds, using the URL: https://jsfiddle.net/5zspem7m/1/ did not prompt for saving the password. Hence, was unable to confirm the issue on those builds.
Attaching screen cast of the issue.
Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Deleted: 783755.webm 5.0 MB

	783755.webm 5.0 MB View Download

Cc-ing battre@ and kolos@ to check wheter they disagree with my assessment of this bug.

The cause on Chrome side:
When the user types into the field, the site changes the field type into 'password' and Chrome registers the field for further filling. However, when the user deletes the characters, the site switches the field type back to 'text' and Chrome ignores that and offers to fill.

I am trying to figure out use-cases for sites to switch between text and password field types (other than to stop Chrome assisting with passwords). One might be to allow showing the typed password on user's explicit request (which is a better alternative to duplicating the password field for confirmation during password reset).

I think keeping the ability to switch field type is desirable to allow an easy implementation of the above use-case. Keeping Chrome assisting the user is also valuable, so as soon as Chrome has a hint that the field is used for passwords, it should offer to fill. It is actually a pity that Chrome cannot fill the field before the user starts typing. Perhaps we could teach Chrome through votes that the field is actually a password field?

To address this particular issue, I suggest that while Chrome fills, it also overrides the type of the field to be 'password'. That means, that immediately after filling, the password will be masked. If later the user or the site decide to unmask, that's fine. The user knows what they are doing, and if the site wants to behave badly, it's the site's problem.

Why do we need to override the type of the field to be 'password'? Would we ever fill if it is not 'password'?

I think Chrome should give to the website the ability to turn off password autocomplete in some way. 
For example in my case above, I want to be sure the user does know the password and it's authorized to perform that action. (it can happen, for example, that people leave their PC unlocked and someone else can get access to it)
Many websites with sensitive information are now forced to use complex hacks to disable chrome autofill, where storing the password is not suitable (for example, bank accounts)

Ad #6 -- As long as the input field never changes its type into 'password', Chrome won't fill it. Once the field does change to 'password' once, Chrome starts to consider it fillable. We could observe the change back to 'text', but then we just enabled an utterly confusing way of saying autocomplete=off.

Ad #7 -- Chrome (security) team has a very firm stance of not letting the website override the user's choice to get assistance with passwords by Chrome [1]. If the team ever changed their mind on this, the autocomplete=off would start to work for passwords again.


[1] https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Why-does-the-Password-Manager-ignore-autocomplete-off-for-password-fields-

Filling on account select of password fields is not implemented on IOS, so this bug has nothing to do with IOS.

I think we should address it once we see multiple real sites doing this technique.

If an input of type='password' is being changed changes to text, I think it would be best if Chrome would clear the field before changing the input type to text.  It seems very wrong that something what was masked as a password would get revealed on screen.