Describe the bug
Not sure if this is classified as a bug/feature request/or request for information, so I'm starting with a bug. I've found an inconsistency in the controls that I'm not sure is intended. Most of the controls seem to accept input when the user tabs out. For dropdown, when you tab out, it reverts back to the last selected value. the user is required to use the enter button to commit the value. I found the closest control "by looks at least" is the color picker, and when the user types a value and tabs out, that value is commited, but this is the case for most other controls where the user types something (calendar control, text box, spinbox, etc...) . Is this the intended behaviour for the dropdown to make the user type the enter key to commit the value?
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I guess I would have expected the tab key to make the selection on the dropdown and move to the next field
Version
Screenshots
If applicable, add screenshots to help explain your problem.
Platform
Additional context
Add any other context about the problem here.
@EdwardCoyle what do you think? This is definitely caused by a change / request to improve the typeahead behavior so its sort of a mix of it not knowing if you typing to filter or typing to select.
I'm not totally sure this is a "bug" or unintentional, but I could see the case for changing it.
The IDS Dropdown component is a glorified wrapper around the standard HTML <select> with filtering. In the standard HTML <select>, it depends on the OS whether or not the functionality of "tab to select what's currently focused" works... on Windows, that's what happens, but not on Mac OSX. There isn't a filtering function on these standard elements, so as far as typing a value goes, there's nothing to compare it with.
In the IDS Dropdown component, the Enter/Spacebar keys commit the value, and the tab key is strictly used for moving in/out of the component. I think historically it's this way because the Dropdown is the "base component" for the Multiselect, which will not implicitly commit any values because the list is expected to stay open between selections (unless you specifically configure it not to stay open). It's also possible to type in a filter value that may not match any available options in the list. The interaction's a bit more complicated than what you get out of the textbox, spinbox, and even the pickers, which don't really have anything in the way of a filter.
Also worth noting that on the Colorpicker sample specifically, if you open the list, navigate with the keys to a defined color, and tab, the "selection" there is also not committed. However, it's true that typing a valid color and tabbing out commits the change.
I suppose we could "standardize" the Dropdown against other components to make it commit changes on pressing the Tab key, but we'd have to figure out some of the complexities:
@deep7102 and @jmacaluso711 might have some good insight here too
Yeah i think probably deal with the complexities and fix for consistency in the future.
True! need to deal with the complexities.
I recently recently received some feedback on this again, so I figured I'd try to get some traction on this again and vouch for updating the behavior and see if there have been any additional side discussions. It appears that the referenced fix does not address the tabbing issue described above.
If there are too many scenarios/edge cases with all the components that use the dropdown as the “base component”, I can appreciate that. We technically only use the dropdown, so would you see any concern over us making the change in our application to allow tab to select the current item and update the field?
Also, the dropdown components keyboard shortcuts page (https://design.infor.com/code/ids-enterprise/latest/dropdown#keyboard-shortcuts) could use a little updating on the description of what the “Tab” key should do. If I didn’t read the “Enter” key description, I would think the tab key should work as I had described in the case above:
Notice the subtle difference of “updates the edit field”.
Thanks for any consideration.
I think perhaps we could change the tab for the dropdown case only and look at this a bit further. Definitely update the docs. I'll push this for deeper investigation next sprint
This was pretty easy to change. Further evidence i see other dropdowns work this way and we had actually documented it as if it was working this way
https://github.com/infor-design/enterprise/blob/master/src/components/dropdown/readme.md
Tab and Shift + Tab moves focus into and out of the dropdown. If the list is open, Tab will close the list, selecting the current item, and tab to the next focusable element
Thanks @tmcconechy
This issue is now resolved. Thank you.
Verified in https://master-enterprise.demo.design.infor.com/components/multiselect/example-index.html?theme=uplift&variant=dark&colors=0066D4 & https://master-enterprise.demo.design.infor.com/components/dropdown/example-index.html?theme=uplift&variant=light&colors=0066D4
Most helpful comment
I'm not totally sure this is a "bug" or unintentional, but I could see the case for changing it.
The IDS Dropdown component is a glorified wrapper around the standard HTML
<select>with filtering. In the standard HTML<select>, it depends on the OS whether or not the functionality of "tab to select what's currently focused" works... on Windows, that's what happens, but not on Mac OSX. There isn't a filtering function on these standard elements, so as far as typing a value goes, there's nothing to compare it with.In the IDS Dropdown component, the Enter/Spacebar keys commit the value, and the tab key is strictly used for moving in/out of the component. I think historically it's this way because the Dropdown is the "base component" for the Multiselect, which will not implicitly commit any values because the list is expected to stay open between selections (unless you specifically configure it not to stay open). It's also possible to type in a filter value that may not match any available options in the list. The interaction's a bit more complicated than what you get out of the textbox, spinbox, and even the pickers, which don't really have anything in the way of a filter.
Also worth noting that on the Colorpicker sample specifically, if you open the list, navigate with the keys to a defined color, and tab, the "selection" there is also not committed. However, it's true that typing a valid color and tabbing out commits the change.
I suppose we could "standardize" the Dropdown against other components to make it commit changes on pressing the Tab key, but we'd have to figure out some of the complexities:
@deep7102 and @jmacaluso711 might have some good insight here too