Update textfield label position when value is changed from JavaScript

[jesperkristensen]

What MDC-Web Version are you using?

Not sure. Neither material-components-web.min.js nor material-components-web.css seem to contain a version number. But the issue looks to be the same on the master branch of this repository.

What browser(s) is this bug affecting?

Tested on Firefox 54 and Chrome 59.

What OS are you using?

Windows 10

What are the steps to reproduce the bug?

I am using MDC-Web together with Angular (v1) following this guide:
https://material.io/components/web/docs/framework-integration/
And specifically this link from the guide:
https://plnkr.co/edit/b4v160c186ErrPG5vNza?p=preview

I have a MDC Textfield as described in the guide above.
When the value of the text field is updated from JavaScript via Angular, the position of the label does not change to reflect if the text field is empty or not.

1. open https://plnkr.co/edit/EMfKHSByb2Z7VaxBOS3K?p=preview
2. Type something in the second text box (the one that is not MDC styled)
3. Observe that the MDC styled input is updated, but the label and the value overlap each other.

When I look at https://github.com/material-components/material-components-web/blob/master/packages/mdc-textfield/foundation.js it seems to set LABEL_FLOAT_ABOVE when the component is loaded and when focus is lost.
But there does not seem to be a way to tell it that the value has been changed from JavaScript, which should update LABEL_FLOAT_ABOVE.

What is the expected behavior?

There should be some API or other way for the framework to tell the component that the text field value has changed, and it should update its label position to match the updated value.

What is the actual behavior?

The field value and the field label are written on top of each other, making them unreadable.

Any other information you believe would be useful?

[traviskaufman]

This does seem like a bug. One possible solution is to simply override the value property on the native text inputs for textboxes, similar to what we do for MDCCheckbox. Thanks for reporting!

[leefernandes]

In the meantime I'm working around this by using a custom label float class to keep the label affixed above.

.mdc-textfield__label--float-above-fixed {
  transform: translateY(-100%) scale(0.75, 0.75);
  cursor: auto;
}

[JordyvA]

Same problem over here. When I manipulate the value in Javascript and set the value over there, the label stays on top of the value. When I click the inputfield (so it get's focus), the label comes above the value.

[thomasklein]

Hi guys! The above PR is already hanging around for a while...

[gjdev]

Since my issue was closed as a duplicate, I'd like to add some info:

AFAIK this issue currently only mentions the label-float style after a programmatic change of the input value. However, a change of the input value may affect other styles when the new value introduces or fixes a previous input value error. Hence value changes may also affect the error styles, helptext, and errortext.

[lynnmercier]

I want to start by apologizing for #1197 unreviewed for so long. We've done a lot of changes around text field lately, and we let this PR slip.

I took a look at the PR, and it's really helped me understand how complicated MDC Textfield really is. There are labels which float and shake...and the invalid states...and the custom validity feature.

Here's what I propose, and I'm hoping @anton-kachurin can help make a PR for this

1. create a new private method updateLabelFloat_

• The LABEL_FLOAT_ABOVE CSS class should only be present if the text field is focused, and the input has value. updateLabelFloat will check for these conditions, and add/remove the CSS class.
• Then replace all references to LABEL_FLOAT_ABOVE within the Foundation code...with a call to updateLabelFloat

2. update changeValidity_ to check if the text field is focused, before adding the LABEL_SHAKE
3. create new private method updateDefaultValidity_

• This method will execute this.changeValidity_(input.checkValidity());
• Then update deactivateFocus_ to call updateDefaultValidity (line 235)

4. create a new public method setValue

• This method will update the input's value
• Then it will call updateLabelFloat
• Then it will call updateDefaultValidity IF the if (!this.useCustomValidityChecking_)

This PR will leave MDC Textfield with the following public methods

• setValue
• setValid (only used by clients who want custom validity checking)

Any time a client wants to change the Textfield's value through JavaScript, that client should call call setValue. And if that client also uses custom validity checking, they should also call setValid

...I realize this proposal is pretty different from #1197. My concern with #1197 is listening to an input property changes. I worry that might not always work across all browsers. I think if a client already wants to set the input value through JavaScript, they should instead be able to set the value through MDC Textfield's setValue.

[acdvorak]

I agree with @lynnjepsen.

In addition, I think we should also listen for input and change events and call setValue() in response. This is necessary to support form fillers like Chrome, 1Password, LastPass, etc.

In my eyes, supporting form fillers is an absolute 100% must. Neglecting them does a tremendous disservice to countless users.

[anton-kachurin]

@lynnjepsen How about all of the above plus hook the value property of the input and call setValue() internally? The hook will need to contain something like if (!this.setValueIsProcessing_) this.setValue(newValue) to avoid getting into an endless loop.

There's too much code that manipulates input's value property directly, we can't just ignore it. Many developers are going to need some solution that allows to maintain proper look of the MDCTextfield after the value property of the native input has been changed.

To provide compatibility with different libraries, plugins, browser extensions, etc, third-party developers are now and will be in the future forced to create workarounds, and these workarounds aren't easy to maintain because "there are labels which float and shake...and the invalid states...and the custom validity feature" and the MDCTexfield component is very far from implementing the spec to its fullest yet.

I totally understand and agree with that property hooks are not ideal from the perspective of the browser support. Older versions of Safari and some mobile browsers do not support it, and IE is being glitchy in some cases. But browser support will get only better over time.

Also, similar functionality is implemented through property hooks in MDCCheckbox. Consistency is important too, in my opinion.

[lynnmercier]

Hmm I hadn't noticed MDC Checkbox doing the same thing. That's very interesting.

We're going to spend a little time doing browser testing of MDC Checkbox...and depending on how that goes we'll update this thread with more information about how to handle MDC Textfield.

[lynnmercier]

MDC Checkbox seems to work fine on all browsers.

So I think @anton-kachurin, you're right. Do all the above plus hook the value property of the input and call setValue() internally

[anton-kachurin]

Will do. Also, I'd like #1503 to be validated. There is a chance that the issue is associated with some property hooking flaws in IE. Update: That issue is not related to property hooking.

[lynnmercier]

Ya..........how about you change #1197 to only cover:

• create a new private method updateLabelFloat_
• update changeValidity_ to check if the text field is focused, before adding the LABEL_SHAKE
• create new private method updateDefaultValidity_
• create a new public method setValue

and then we will all figure out a follow up PR to cover the property hooks. Hopefully by then we can investigate the IE side of things more within the context of MDC Checkbox, and can provide some guidance

[anton-kachurin]

Working on it. Some progress may be seen in #1197 but that's not a final version. Still need to:

1. Add tests for the new public setValue method
2. Add docs for it

By the way, since we are adding a public method to the foundation, seems reasonable to add:

1. A new public getValue to the foundation
2. MDCTextfield.value property to the Textfield API

WDYT?

[lynnmercier]

Added

A new public getValue to the foundation
and
MDCTextfield.value property to the Textfield API

in #1873