Selecting text in the input can lead to reset()

• downshift version: 1.27.1
• node version: 8
• npm version: 5.5.1 (But I believe all versions are concerned)

When clicking to select the text from the input that downshift controls, if you end the selection outside of the input it can end up resetting the input to the selectedItem value, while the user is actually trying to interact with the input and select the full text to replace it.

It is reproducible on the simplest version of downshift from the examples in this repo : https://codesandbox.io/s/6z67jvklw3

Steps to reproduce are the following :

1. Type and select banana
2. Change bananato bana
3. Click on the input, slightly to the right of bana (so not directly on the text)
4. Select the full text, and end the text selection outside of input The input is reset to banana, whereas you were trying to edit it.

(If this description is not perfectly clear, which I assume could be the case, I may do a video to demonstrate this, feel free to ask)

The problem clearly comes from https://github.com/paypal/downshift/blob/master/src/downshift.js#L832

Suggested solution: I believe a check could be added to know if the mouseDown event happened on the input, if it’s the case downshift should not reset. I tend to believe though that this reset on outerClick is not necessarily useful, as downshift is already resetting onBlur and I cannot see any use case right now where outerClick will happen, but not onBlur, except the one from this bug.

[jduthon]

I was thinking of something similar, even though I would personally go with a onMouseDown on the input and items, so the isMouseDown would still be useful as a boolean, maybe rename it to wasInnerMouseDown. And then just check if wasInnerMouseDown, if it’s true then just set it to false and that’s it as the mouseUp is matching it, otherwise do what is done now : reset the state and call onOuterClick. Advantage of this one I believe is not to listen to all the mouseDowns but only the one we are actually interested in.

[kentcdodds]

Thanks @jduthon!

I believe a check could be added to know if the mouseDown event happened on the input, if it’s the case downshift should not reset.

I think this makes sense. Feel free to make a pull request for that 👍

Thanks so much