React-select: Support home and end keys for text Input

[CaptainKant]

Hello and thanks for this library.

On my laptop keyboard, "home" and "end" keys don't work inthe input search field.

So, I can't move the caret to the start, to the end, or full select the content of the input search field, without press many times arrows keys.

[lmvco]

In fact, I looked at the code and I realized that, when the menu is opened, the "home" and "end" keys selects the first and the last option.

File Select.js

      case 'Home':
        if (!menuIsOpen) return;
        this.focusOption('first');
        break;
      case 'End':
        if (!menuIsOpen) return;
        this.focusOption('last');
        break;

I agree with CaptainKant. The home and end keys should have effect in text input. Or, at least, there should exist a prop to customize this behavior.

[OasisLiveForever]

I agree with @lmvco , Home and End should have effect in text input, like a normal input.

[haydencrain]

Having a similar issue. It's become a habit for me to press Shift + Home when wanting to highlight an entire block of text within an input field.

It seems the Home/End list support was added in #1003

Having an option to choose between either using the home and end keys for list or caret manipulation would be awesome (potentially by 'opting-in' to the Home/End list pagination support).

[jd327]

Hey @JedWatson, any idea if there's a chance this gets implemented any time soon?

[quaternion7]

I've come up with this workaround:

const handleKeyDown = (evt)=>{
   switch(evt.key){
        case "Home": evt.preventDefault();
            if(evt.shiftKey) evt.target.selectionStart = 0;
            else evt.target.setSelectionRange(0,0);
            break;
        case "End": evt.preventDefault();
            const len = evt.target.value.length;
            if(evt.shiftKey) evt.target.selectionEnd = len;
            else evt.target.setSelectionRange(len,len);
            break;
    }
};
<Select onKeyDown={handleKeyDown} {...} />

It's not the prettiest workaround, but it does the trick until someone implements the option as props.

[Slapbox]

@JedWatson it would be really helpful to have an option to enable the default behavior of Home and End instead of the overrides introduced by react-select.

In the examples it doesn't make much sense, but in the real world this is a legitimate issue.

@quaternion7's solution is decent, but things like scrolling the view within the input to make the caret's position visible don't occur with this solution, at least in Chrome.

[ebonow]

Greetings,

First of all, I think it's worth identifying that the menu behavior is consistent with a Select DOM element. Home focuses the first option, End focuses the last. Since react-select is designed to be a drop in replacement for a Select, it seems that this should be the default and expected behavior though I can certainly also understand the discrepancy in expectations.

Secondly @Slapbox I think it is worth identifying the issue in your expectations is OS specific.

• Windows uses the Home and End keys to move the selection cursor to the beginning/end of the text input. On OSX, this is the equivalent of fn + left/right

• OSX uses the Home and End keys to scroll the window to the top and bottom of the page while maintaining focus on the input. Additionally a double-click can return the user to the original scroll position. _(My mistake, this was me letting go of fn key early on second click, which scrolled the input into view and moved text cursor position in the direction of the arrow key)._

With this in mind, it seems problematic to try to reimplement standard keyDown behavior because of native OS differences in behavior.

I think the behavior should default to that of a Select, however, it should be possible to override this behavior and as it is, I am not sure how feasible it is to detect click/double-click and perform different behaviors based on some kind of OS detection.

I will leave this open because I agree that it should be more flexible to modify the key defaults and perhaps a prop might better serve this kind of feature.

[Slapbox]

Very sensible reply @ebonow!

I'm not an OSX user except when I need to be; would you mind clarifying this OSX behavior?

Additionally a double-click can return the user to the original scroll position.

---

The reason it didn't occur to me that Home & End already have native activities in select elements is that the idea came to me while I was testing with a string that matched no items our list. It would be awesome to have the behavior match the OS default for a text input in these circumstances - but since that's more of an edge case, it's really just a nice-to-have.

[ebonow]

I tried testing Windows behavior on a VM last night, but also not sure if it emulated correctly, but from what I saw on the VM was that it simply moved the cursor position to the first or last text position. I'll verify later on my Windows laptop later.

Here is a codesandbox I am using for testing with the coding implementation from @quaternion7:
https://codesandbox.io/s/react-select-home-endkey-testing-5o6ms?file=/src/App.js

[Slapbox]

@ebonow that code snippet works great on Windows, just tested. It's been so long since I first joined this thread that I forgot that snippet was up there.

[ebonow]

Haven't missed too much in that time up until about a month ago. Jed is back in the conversation so doing my best to clear out as much as possible so we can get through the backlog of issues and PRs trying to stuff as much as possible into next release.

Just tested this one on Windows and it appears to mimic the intended behavior. In regards to scrolling the page for OSX, I would venture to say that it's probably not as important. I'd be willing to close this and include this as a viable example on a show and tell page I am putting together of various different examples.

What are your thoughts on closing this?

[Slapbox]

I think the snippet @quaternion7 shared is a sufficient workaround - at least from my perspective as a Windows user. I'm not familiar enough with OSX's default behaviors to have any opinion.

It would be nifty if such an option was built into React-Select, but I think that the right mindset for library devs is to cut the fat - and I think this feature request would _probably_ qualify as "the fat."

So you can probably close this, even though my personal preference as an end user would be to have the simplicity of a boolean to pass the <Select />

[ebonow]

Totally reasonable, and I agree. Some opinions had to be made about default behavior. I actually had a ticket created for this feature at my work so I'm glad I came across this issue.

I should have an examples/how-to discussion up soon and will be sure to include this example from above.

I will close this and keep this conversation in mind when we get to the larger rewrite with hooks. Thank you for your feedback on this issue and talking through it. It's appreciated.