Skip to content
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

disabled on mdInput doesn't work when formControl directive is used(works with native el) #2667

Closed
fxck opened this issue Jan 16, 2017 · 6 comments
Assignees

Comments

@fxck
Copy link
Contributor

fxck commented Jan 16, 2017

see http://plnkr.co/edit/AvPMHB3lzqwaexypHkUR?p=preview

I've read some issues on angular/angular and apparently disabled shouldn't work at all when reactive forms are used. But it looks like it does on native elements and doesn't on element with mdInput directive.

cc @kara

@fxck fxck changed the title disabled on mdInput doesn't work when formControl directive is used disabled on mdInput doesn't work when formControl directive is used(works with native el) Jan 16, 2017
@kara
Copy link
Contributor

kara commented Jan 17, 2017

cc @mmalerba

@RicardoVaranda
Copy link

+1 Seems like disabled Input has a few issues:

https://plnkr.co/edit/HEJze0spwbiQS558SvrE?p=preview

@mmalerba mmalerba self-assigned this Jan 20, 2017
@emin93
Copy link

emin93 commented Jan 24, 2017

I can reproduce this bug, but it seems to work when adding the disabled directive manually.

<!-- Doesn't work properly -->
<input md-input [disabled]="false">
<!-- Works -->
<input md-input disabled>

@mmalerba
Copy link
Contributor

@kara I think this is a result of #2565. you changed it so that if a form control is present that takes precedence. Is this current behavior the correct behavior?

get disabled() {
  return this._ngControl ? this._ngControl.disabled : this._disabled;
}

or do we want this?

get disabled() {
  return this._ngControl ? this._ngControl.disabled || this._disabled : this._disabled;
}

@kara
Copy link
Contributor

kara commented Jan 26, 2017

Discussed offline with @mmalerba. In short, the behavior is right in that the control should always take precedence over the disabled property. Otherwise, if you disable the control programmatically without setting the disabled property (as is typical of reactive form pattern), the input will not pick up the new disabled state. The internal property is really intended for forms that aren't using either of the core forms modules.

@fxck is correct that standalone (unbound) disabled values* do behave slightly differently from how they work in native inputs. While both throw warnings in the console that the pattern is not recommended, mdInput completely ignores the property, whereas native inputs kind of work in that they disable the UI (though they don't update the control). I'm not certain that we want to spend time to make the unbound disabled property "kind of" work, given that it's already a pattern we're warning people not to use. This is an area that we should really work on in Angular core because the behavior still isn't consistent. For that reason, I'm closing this issue. If anything, a change should be on the other end.

*As opposed to doing something like [disabled]="isDisabled", where both inputs ignore it.

@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
None yet
Projects
None yet
Development

No branches or pull requests

5 participants