This PR is different from #4871 in that it highlights the arrow on tab:

Versus #4871:

I wasn't able to find a material spec for this, but it is a notable difference between the two. Personally, I prefer the animation in #4871.

@petermikitsh The animation here can be changed to include the textbox underline, that's not a big deal. The big deal is that this also adds keyboard support to DropDownMenu's that are NOT inside of a SelectField as well. Go to /#/components/dropdown-menu to see that it still works there, where #4871 doesn't.

I get the technical benefits to this PR, but I visually prefer #4871. Maybe we could get the best of both worlds and combine the two?

@petermikitsh in DropDownMenu.js line 234 and 238 - that's the reason the TextField doesn't recieve focus events.. I was trying to get it to work so it would underline the textbox at first, but when TextField gets a focus or blur event it does a setState, which re-renders its children and causes the drop down to lose focus. I couldn't get it to work that way but agree that it would be optimal. Do you want to take a look at this? just comment those lines and you'll see what i mean.

Yeah, lines 234 and 238 prevent TextField from receiving events. That's why I implemented a new prop, onClose, that can be passed into DropDownMenu. The SelectField passes in this function to DropDownMenu, which focuses the TextField component.

@petermikitsh Right, i re-focus on the drop down close too (inside of DropDownMenu instead) but a new prop doesn't fix anything if you're focusing the DropDownMenu instead of the TextField (which is what should happen). If you focus the DropDownMenu again TextBox still re-renders and the focus ends in no-where-land. The only reason #4871 works with an extra prop is because the TextBox holds the focus and not the DropDownMenu and that's the whole problem I have with that pull.

Both pull's have problems, and I don't care which gets accepted, but IMO the right solution is finding a way to handle focus events in DropDownMenu, and bubble the events up to TextField without screwing up the active element.

Probably a dumb question, but why is there both a DropDownMenu and SelectField?

http://www.material-ui.com/#/components/dropdown-menu
http://www.material-ui.com/#/components/select-field

They seem visually and functionally identical.

<DropDownMenu value={this.state.value} onChange={this.handleChange}>
  <MenuItem value={1} primaryText="Never" />
  <MenuItem value={2} primaryText="Every Night" />
  <MenuItem value={3} primaryText="Weeknights" />
  <MenuItem value={4} primaryText="Weekends" />
  <MenuItem value={5} primaryText="Weekly" />
</DropDownMenu>

<SelectField value={this.state.value} onChange={this.handleChange}>
  <MenuItem value={1} primaryText="Never" />
  <MenuItem value={2} primaryText="Every Night" />
  <MenuItem value={3} primaryText="Weeknights" />
  <MenuItem value={4} primaryText="Weekends" />
  <MenuItem value={5} primaryText="Weekly" />
</SelectField>

@petermikitsh DropDownMenu has a wider use-case than SelectField. DropDownMenu could, for instance, be a drop down of links that upon click direct you to different pages. SelectField is for form input where the user can change the selected value (which is not necessarily true of DropDownMenu).

DropDownMenu is important, especially for writing your own components with custom function as SelectField is locked into the purpose of being an input essentially.

I don't know why this is a debate. Clearly #4871 breaks the re-usability of DropDownMenu, and for what? a different visual style?

Does #4871 break DropDownMenu functionally?

Give me a second, I'm making more changes.

It doesn't break what's already there, but accessibility of DropDownMenu and SelectField has been on the issue tracker for a while and #4871 will need to be reverted if keyboard support is ever to be added to DropDownMenu and that doesn't make sense since this pull already addresses both components.

#4871 will need to be reverted if keyboard support is ever to be added to DropDownMenu

I just merged our two branches and that seems to not be the case.

For sake of parity, I can support this change set over #4871.

@petermikitsh @caesay

Don't worry too much about the future because there is a semi-rewrite coming up in the next few months. The semi-rewrite is being done with not just keyboard accessibility in mind, but I am also testing every single component with a screen reader.

@petermikitsh If you check I've fixed the visual style so that it underlines the textbox as well how you like!

@nathanmarks So does that mean this won't get accepted? should I also open a pull request that adds keyboard support to the DatePicker component or is it the same situation there?

@caesay they'll definitely still be accepted, there is another breaking release coming for master now. I'm just saying don't invest too much time worrying about making things absolutely perfect as this code will not stay in the long term.

Underlying components such as Menu and TextField are being completely rewritten. There are a lot of problems in the current version of MUI that are very difficult to fix incrementally. In next, the keyboard accessibility features are built into Menu itself.

In addition to fixing keyboard accessibility for menus, I've also added in a critical UX feature that we are currently missing: opening menus to the currently selected item.

@nathanmarks is the breaking change part of the next branch? I'm looking to enable keyboard navigation within this component and would much prefer that this go in and then get overridden when next is ready for prime time. Who needs to review this so that it can be merged into master?

I decided to go ahead and review it myself, and found a number of problems with my controlled component, evidenced by this GIF:

1. The dropdown arrow has changed color from light gray to black.
2. When activating the dropdown, onChange seems to be fired, because my error validation immediately kicks in.
3. Tabbing away clears the field. I'm pretty sure the field should never be cleared.

@petermikitsh you closed PR#4871 in favor of this. But there is useful feature at that PR - onClose prop for DropDown component. It would be prefect to save it.

Did this ever make it into a release?

I'd like to know if this is going to be released as well. The ability to tab to a select field when filling out a form is a necessity for my project. If this will not be released I'll take a stab at implementing it myself and will submit a PR.

Here is a bug for the issue: #5498

My project also would benefit greatly form this PR.

I have opened #5921 to bring this PR into master. Any feedback is welcomed 🙏 .