md-input-container: Password label not floating with Chrome password-manager auto-fill

[SebiH]

When using the password manager in Chrome to automatically fill in username & password on two md-input-containers, the password label will not float until some action (e.g. clicking anywhere on the page) is done:

After initial page load:

After clicking anywhere:

Reproducing this isn't very easy, since services like Plnkr or CodePen either won't trigger the password manager or the auto-fill; however this GitHub page / repository should provide an environment where it should be reproducible:
Site: http://sebih.github.io/angular-material-pwmanagerbug/
Repo: https://github.com/SebiH/angular-material-pwmanagerbug

As there isn't any password authentification, simply type in something to (hopefully) trigger Chrome's password manager, save password and use the link to go back to the login page.

One interesting thing to note is that refreshing the login page does not seem to recreate the faulty state; however navigation via links breaks the password field again.

It seems to work properly in FireFox 35. I'm using Chrome 40, but noticed it in previous versions, too.

[marcysutton]

Pretty sure this is due to a bug in Chrome where password autofill doesn't trigger a change on inputs. Not sure there's much we can do about it until it gets resolved.

[morrissinger]

I know this is closed, but this has been a Chrome bug for some time and it may not be resolved for a while for all I know. So, I think, in the spirit of finding some solution as a workaround, this might be useful to people:

document.querySelector("input[type=password]").value = " ";
document.querySelector("input[type=password]").value = "";
document.querySelector("input[type=password]").blur()

This clears an autocomplete value, so there is some drawback to this approach. However, it looks nicer. You might also be able to use autocomplete="off", but I haven't been able to solve this issue that way.

[ThomasBurleson]

Should be fixed in #master with SHA a64291b

[SebiH]

Problem seems to persist on Chrome (v43). I've updated the test repo/site since it returned 404, but should be up now again. Will test the workaround later.

[morrissinger]

I don't think we are out of the woods just yet, even given a64291b. I tried a few things to determine this. I:

• Bower installed angular-material: bower install --save angular-material. This did not fix the problem.
• Bower installed angular-material#master: bower install --save angular-material#master. This did not fix the problem.
• Bower installed a64291b: bower install --save angular-material#a64291b. This did not fix the problem.
• Built angular-material from a64291b: git clone https://github.com/angular/material.git; cd material; npm install; gulp build and then I copied the build over to the project where I am using angular-material and rebuilt my project. This did not fix the problem.

[ThomasBurleson]

@Splaktar - can you investigate this?

[morrissinger]

Another point: the bug appears to have an intermittent nature. I can refresh @SebiH's repo/site and sometimes see the issue and sometimes not see the issue.

Here is my screenshot:

[SebiH]

@morrissinger Seems to be related to keyboard events, possibly? On my machine, when refreshing via navigation or clicking the reload button with the mouse, the password label will not position itself correctly. When refreshing with F5, it works as expected.

[alirezamirian]

This is because of this weird Chrome behavior:
The value of autofilled password field is not set until user do any kind of interaction with page, including clicking somewhere or touching almost anything in keyboard!
This is described in more detail here.
I don't know it's because of security or something but it becomes bolder in angular-material, because of the floating label, however it exists even in big websites like Dropbox
I tried a various kinds of workarounds including simulating mouse or keyboard interaction, but none of them worked! It seems to be such an intractable bug!
One possible amelioration is to use "md-no-float", but doing that, not only you will lose the awesomeness of floating label, but also if you want to use form invalidity state to enable or disable submit button, problem remains!

[Splaktar]

As @SebiH stated in his last comment, this does have some interaction with exactly how the page is refreshed.

• Doing a ctrl-R or F5 keyboard refresh causes the input to render correctly. This is likely due to the key release triggering Chrome's input detection.
• Doing a soft refresh via the browser button causes the input to render incorrectly.
• Doing a hard refresh via the browser button while holding shift causes the input to render correctly, in some cases. This is because the shift key is released, that event triggers Chrome to detect interaction and then process the auto filled input (i.e. float the text).

Just pressing any key after reloading the page w/ a problem causes the input to float the text properly.

Based on the two Chrome bugs referenced in this issue plus an additional duplicate Chrome bug (https://code.google.com/p/chromium/issues/detail?id=398805), this appears to be Working as Intended in Chrome.

There are hacks available. TBosch came up with https://github.com/tbosch/autofill-event just for this kind of issue. Unfortunately, I was not able to get that to work for me with the latest Angular about 9 months ago.

I was able to solve this in one project for Firefox by using a $timeout, details here: http://stackoverflow.com/a/23919364/633107

But this hack does not appear to work for Chrome due to the above mentioned bugs related to Chrome AutoFill. The ngModel is never updated with the value from AutoFill until the user interacts with the page in some way.

Also as for the reason that the Placeholder text does not behave properly, this is related to the fact that md-input uses a <label> instead of a placeholder. Chrome doesn't handle labels like a placeholders as per the spec.