Handle focus if ng-disabled is used

[SantjagoCorkez]

Just as this plunk: http://plnkr.co/edit/madPC9CfslTh9BTOJaee?p=preview when ng-disabled is mapped to the same scope var as typeahead-loading, the input box doesn't restore focus which is surely lost on ng-disable trigger.

May it somehow be related to #2598 and #3223. If not, let this issue be a feature request.

angular: 1.3.9
ui-bootstrap: 0.12.0

[dmitriz]

Looks like a bug!

Typing immediately sets the expression of typeahead-loading to true in
https://github.com/angular-ui/bootstrap/blob/master/src/typeahead/typeahead.js#L127
and then makes ng-disable=true, which effectively disables the input and closes the pull-down.

What makes it worse, any other change on the scope that makes the ng-disable expression evaluating true, will effectively terminate the widget.

It would probably be good to make sure the input is not disabled during the whole lifecycle, until the selection is made?

I can imagine a use case when the app makes a server request upon user selection and wants to "freeze" the selection by disabling the input.

[SantjagoCorkez]

I'm using it right this way: the input field should resist any user input attempts while the underlying AJAX call is in progress (because of unpredictable behaviour otherwise). But I've then moved from ng-disabled to ng-readonly. This at least does not trigger element's blur automatically. As I've stated in #3223 this at least could be especially noted in the documentation.

[dmitriz]

As the AJAX is asyncronous, I would not block the user from typing. The typeahead will keep trying to match whatever the user enters as soon as possible, which is correct. Its behaviour is supposed to be completely predictable based on the input value and the most recent data.

The only use case I would want to disable typeahead is when selection is already made, and you are waiting for a syncronous request, which wouldn't be related to typeahead. For instance, you first choose an item using typeahead, and after choice is made, you order it. Surely you don't want to order twice, so it is a good thing to disable the whole form. But this only happens during the 2nd syncronous request.

[wesleycho]

Maybe debouncing the request call would be more appropriate for UX reasons.

[wesleycho]

Going to close this as something we won't support - this seems to have issues, such as knowing what the intentions are when toggling the disabled state. I highly would recommend against doing this.