Skip to content

md-input displays value on top of placeholder if disabled and value is bound from a component class property #2816

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
marcoross opened this issue Jan 26, 2017 · 10 comments
Assignees
Labels
P2 The issue is important to a large percentage of users, with a workaround

Comments

@marcoross
Copy link

Bug, feature request, or proposal:

md-input displays value on top of placeholder if disabled and value is bound from a component class property

What is the expected behavior?

The placeholder shall be smaller and displayed above the value

What is the current behavior?

The placeholder is displayed with a larger font size behind the value

What are the steps to reproduce?

See the company input field in this plunk:
https://plnkr.co/edit/J9e4gAkC5jIEdTbyUbqd?p=preview

What is the use-case or motivation for changing an existing behavior?

Want to use placeholder values on non-editable fields in a form to have the same name->value pattern for all items in the form.

Which versions of Angular, Material, OS, browsers are affected?

@angular/material 2.0.0-beta.1
@angular 2.4.2

Is there anything else we should know?

@wadenweh
Copy link

Same problem here.

Which versions of Angular, Material, OS, browsers are affected?

    "@angular/compiler": "^2.3.1",
    "@angular/core": "^2.3.1",
    "@angular/forms": "^2.3.1",
    "@angular/http": "^2.3.1",
    "@angular/material": "^2.0.0-beta.1",
    "@angular/platform-browser": "^2.3.1",
    "@angular/platform-browser-dynamic": "^2.3.1",
    "@angular/router": "^3.3.1",

@marcoross
Copy link
Author

Workaround: The issue does not occur when the [ngModel] binding is used instead of [value]

@zigfry
Copy link

zigfry commented Jan 27, 2017

This bug occurs even if the field is not disabled. I am having the same issue using reactive forms when I set the value outside of the onInit method (for example after fetching data from API).

The end result is that the md-empty class still remains on the input component's label, even though a value is set. I am using this method to 'patch' a single control's value:

//THIS UPDATES THE FORM CONTROL VALUE - BUT NOT THE LABEL'S MD-EMPTY CLASS
(<FormGroup>this.myForm).patchValue(myData, { onlySelf: true });   

where this.myForm is a FormGroup and myData is an object that has properties named the same as the controls in myForm.

See this plunk: https://plnkr.co/edit/nDrY5UhWSGe3jMtgGuHb?p=preview

@jelbourn jelbourn added the P2 The issue is important to a large percentage of users, with a workaround label Jan 27, 2017
@mmalerba
Copy link
Contributor

This has been fixed in master, just needs a release

@zigfry
Copy link

zigfry commented Jan 27, 2017

Excellent! I just worked that out with a new plunk which works with the master version:
http://plnkr.co/edit/ExCcGDx8GEypp4XFAAqW?p=preview

Do you know when the master will be released?

@marcoross
Copy link
Author

Excellent, that's great news! Thank you!

@leonardovff
Copy link

When then next released? @mmalerba

@mmalerba
Copy link
Contributor

We're working on it. There's a couple important changes we want to get in first, can't give an exact date yet, soon though

@leonardovff
Copy link

leonardovff commented Jan 30, 2017

I used this temporarily:
let el = document.querySelectorAll('input[formcontrolname]'); for(let indice = el.length; indice>0; indice--){ el[indice-1].dispatchEvent(new Event('input')); }

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P2 The issue is important to a large percentage of users, with a workaround
Projects
None yet
Development

No branches or pull requests

6 participants