Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

explicitly call .blur() on select? #1254

Closed
Pomax opened this issue Sep 27, 2016 · 6 comments
Closed

explicitly call .blur() on select? #1254

Pomax opened this issue Sep 27, 2016 · 6 comments
Labels
issue/reviewed Issue has recently been reviewed (mid-2020)

Comments

@Pomax
Copy link

Pomax commented Sep 27, 2016

We're using react-select as one of the many field types in a form, and our form component has the following simple logic to ensure that if any field is set to "Other", a text field is revealed in which users can fill out their out-of-band choice/reason/etc.

  // autofocus on anything that needs autofocussing.
  componentDidUpdate: function(prevProps, prevState) {
    var afelement = this.refs.autofocus;

    if (afelement) {
      if (document.activeElement) {
        document.activeElement.blur();
      }
      ReactDOM.findDOMNode(afelement).focus();
    }
  },

This works perfectly, except when "Other" is chosen in react-select. In that case, React honours the focus() call in componentDidUpdate, and then react-select immediately steals focus back, which it should not be doing.

Is there a way to tell react-select to stop hogging the limelight?

@divmgl
Copy link

divmgl commented Feb 24, 2018

This is an old issue, but I'd like to see the addition of a blur option or the ability to NOT focus the select when selecting an item.

@bladey
Copy link
Contributor

bladey commented May 27, 2020

Hello -

In an effort to sustain the react-select project going forward, we're closing old issues / pull requests.

We understand this might be inconvenient but in the best interest of supporting the broader community we have to direct our limited efforts to maintain the latest version.

If you feel this issue / pull request is still relevant and you'd like us to review it, please leave a comment and we'll do our best to get back to you.

@bladey bladey closed this as completed May 27, 2020
@Pomax
Copy link
Author

Pomax commented Jun 1, 2020

it might be 4 years old, but unless this got fixed: this is technically a UX and accessibility bug.

Elements should be assigned focus by the browser, based on what it knows about whether code or a user did something. It should never indiscriminately claim focus on its own. Setting a value on a form element should only set the current value, and do nothing else.

@bladey
Copy link
Contributor

bladey commented Jun 1, 2020

Thanks @Pomax!

@bladey bladey reopened this Jun 1, 2020
@bladey bladey added the issue/bug-unconfirmed Issues that describe a bug that hasn't been confirmed by a maintainer yet label Jun 1, 2020
@bladey bladey added the issue/reviewed Issue has recently been reviewed (mid-2020) label Jun 17, 2020
@ebonow ebonow added the awaiting-author-response Issues or PRs waiting for more information from the author label Dec 4, 2020
@ebonow
Copy link
Collaborator

ebonow commented Dec 4, 2020

Greetings @Pomax ,

This has indeed aged a bit, and I am not able to replicate the issue.

In my test setup, I have a react-select and an input.

  1. The input is set to autofocus.
  2. onMount, a 3 second setTimeout is set to update the value of the react-select.

The test shows that the select-value is set without stealing focus from the input. Please let me know if I am misinterpreting the use-case you are trying to achieve as I would like to have any long standing issues resolved without any loose ends.

@Pomax
Copy link
Author

Pomax commented Dec 4, 2020

I updated your code to reflect the situation we had and do not see it acting anomalously anymore, so that looks fixed.

And on a small React note, if you're already returning a single element (in this case, <div>) no need to wrap it in a fragment (the <>). Fragments are only necessary if you would otherwise be trying to returning a bunch of "loose" elements.

Thanks for following up!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
issue/reviewed Issue has recently been reviewed (mid-2020)
Projects
None yet
Development

No branches or pull requests

4 participants