onBlur behaviour is affected by "touch capabilities"

Are you reporting a bug or runtime error?

That’s not really a bug, and not an error - this is a not correct behavior.

There is an option - blurInputOnSelect

• blurInputOnSelect: isTouchCapable(),

and the effect of it quite simple:

  selectOption = (newValue: OptionType) => {
    ....
    if (blurInputOnSelect) {
      this.blurInput();
    }

Problems

1. Should it be delayed? In normal conditions there are two different events (click/change, blur) comes one after another with a little “gap” between them. But in this case - there is no gap. This results into some differences in the “state management” - blur evens is reported too soon - before the change(or select) event is finishing propagation (state change applied back to the component). Probably onBlur should be called in setTimeout, or at least a Promise

2. Should it even exists?
   For all “touch devices”, windows 10 on hybrid devices included, or only when select is caused by “touch” event? Probably here we should check touch event, and execute blur only there, but not as a part of selectOption

3. Is it a real problem? Yes, it is. We run into it twice this year, causing SEV1s both times.

[tstelzer]

Yup, though we’re using setTimeout(f, 0) instead of setImmediate(f).

[tstelzer]

I believe we are having issues stemming from this as well, on touch devices the onBlur triggers before onChange, sometimes, which prevents the change event entirely.