As I noted in the description above:

This is meant to explore correctness of the behavior. I expect that the exact API signature and any theme configuration will need additional contemplation.

So, I am fully anticipating a conversation on "when" to do this and "how" to make it a default.

I was really struck by the comments that different browsers have different default behavior for the native element. Firefox's default behavior for <select /> is as this pull request does it, where tab closes the drop and moves to the next focusable inline element. I was also compelled by the comment about the un-naturalness of not matching the default browser behavior. I'm wondering if we should offer two fundamental modes for grommet's Select that align with the browser default behaviors and then allow a theme configuration that indicates whether the default should be a specific one or whether it should match the browser's default behavior for the native element. It would be easy to cover the top browsers and default to one of the modes for all others.

Thoughts?

I'm summarizing some thoughts from our conversation today so the team can chime in as well.

Since the select's native behavior varies between browsers, we should be mindful to pick a default tab behavior per user's browser.
Enabling inline will allow us to support browsers such as FF.

Since we want the users to have consistent behavior of different instances of Select across the app, we would leverage the theming capabilities to state the desired tab behavior as follows:

   select: {
      keyboard: {
        tab: <value>,
      },
      ...
   }

Potential values for <value>:

1. "native" - would default to the user's browser behavior.
2. "closeAndForward" - would close the drop and move up to the next interactive element (inline will probably need to be injected into the drop).
3. "ignore" - would ignore the tab when the Select is opened (similar to Chrome native select that swallows the tab event).

I think we can start with the options above, and enhance them as the need arises.

Few more points to consider:

1. Grommet would like to provide a Select that will have a reasonable tab behavior out of the box, without additional configuration, one way to do it is to default the theme to the "native" approach. Can you think of any backward compatibility issues that this change may result in?
2. Should we support tab configuration up high on the Drop component theming, so it can allow consistency between different grommet components that uses drop (such as Select, DateInput, Menu...). This alternative will be opt-in since it may cause backward compatibility issues when changing its defaults. But I'm wondering what are your thoughts on this.

Please let us know what you think.

1. Grommet would like to provide a Select that will have a reasonable tab behavior out of the box, without additional configuration, one way to do it is to default the theme to the "native" approach. Can you think of any backward compatibility issues that this change may result in?

I think if we are defaulting the theme to the native browser approach and aligning the tab behavior to how the browser would handle a native html select, I see this as a fix. We have done previous accessibility work aligning our components with how the native html component is working so I don't see a backwards compatibility issue with this. I see it as fixing the component to align with how the browser would handle the native html version.

2. Should we support tab configuration up high on the Drop component theming, so it can allow consistency between different grommet components that uses drop (such as Select, DateInput, Menu...). This alternative will be opt-in since it may cause backward compatibility issues when changing its defaults. But I'm wondering what are your thoughts on this.

Yes I do think we should allow the theme to control the overall drop behavior for the application, not just the Select component. To me it makes sense to set the tab behavior for drop's across the whole application.