Improve handling under iOS #1127
Conversation
|
Changes Unknown when pulling 4436954 on zeitiger:master into * on selectize:master*. |
|
Changes Unknown when pulling 3bb3453 on zeitiger:master into * on selectize:master*. |
|
Thanks. The UX makes a lot of sense to me in the scenario you describe. I'm just wary about adding yet another option. Is there a way we can make the default better? |
|
Yep. Actually, having tried this on iOS, having the keyboard still out after selection makes no sense. Let's make this default behavior. However, the control input must only lose focus in a case like this, where we have a select. When we have an input, the dropdown should close, but the control must not lose focus. I think we'd need to enumerate the use cases to provide solid defaults. |
|
After I get the broken test, I thought that focus thing was as designed, why else would be assertion for this detail ;-) Yes to lose focus within tag mode make no sense, I only use this widget for a improved vanilla select. So next step, I kick out the option and check that we are on single mode and made a selection and has btw. thanks for your work here, I really appreciate your positiv response 😸 |
|
Changes Unknown when pulling e9dd293 on zeitiger:master into * on selectize:master*. |
|
Squash that with a concise/descriptive commit message, and we'll be good for a merge |
|
Also, don't forget to add a Changelog line! |
- tweak handling under iOS - improve blur handling and add option - improve pullrequest based on helpful feedback - change CHANGELOG
|
done |
|
Changes Unknown when pulling 4be1964 on zeitiger:master into * on selectize:master*. |
Under iOS
This pull request fix this issue, with removing focus on hidden text input field, within close event handling.