We'll need to see if that's an easy fix or not. Do all other forms work well? Wondering if it is a materialize.css issue or an issue with our code.

I did not check other forms, just confirmed the message in forum on our test VM.

I've debugged for quite a while and found out that the disabled attribute is causing it. Was at first thinking that it accidentally sets a disabled attribute on the input form, but the problem is actually the disabled attribute on the DIV element that defines the form component. When removing this attribute, everything works as expected.

Calling Materialize.updateTextFields() fixes the issue, but would need to be called after every field change/keystroke/... so this is not a solution.

Seeing there is eg this code:

Haven't debugged this further, couldn't really find a fix so far. Wonder if it is some IE or jquery bug.

Adding a placeholder attribute with an empty string kind of worked

and made the label appear correctly but the text was still shown like it is disabled...

for some reason this prefix for placeholder is applied for the color:

the only solution I can think of so far is to provide an alternative attribute and deprecate disabled in field-directive.js. Could use matomo-disabled=... or disable=. This worked for me as a workaround.

@fdellwing @diosmosis any thoughts maybe?

I can confirm, that the disabled is causing the issue. If it is not a big deal, the easiest solution would be to refactor it to something different. To not break with HTML specs I would propose data-disabled.

@fdellwing genuis! :) actually angular already supports data-disabled so we don't even need to do anything and no BC issues etc when making plugins compatible... :)

See https://docs.angularjs.org/guide/directive

just double checked and changing it to data-disabled worked in IE