React-color: EditableInput with focus doesn't change value

[davesnx]

Hey @casesandberg

I found a potential bug on EditableInput. When EditableInput is focused and you drag a Saturation or a Hue, the value doesn't change.

I create a small demo. You can edit it here: https://codesandbox.io/s/n53766998j

Just trying to debug the problem seems that if you change it by a normal input this "bug" disappear.

The problem may be that the EditableInput doesn't receive new props and doesn't trigger
componentWillReceiveProps: https://github.com/casesandberg/react-color/blob/master/src/components/common/EditableInput.js#L14.

and btw, thanks for react-color, it's anwesome lib!

[yadomi]

Hello,

I don't want to say something wrong but this seems to be the normal behavior of <EditableInput/> (eg: here ) since value is updated only if the input is not focused. However i'm not sure why this was made that way.

Using this.props.value instead of this.state.value for the value prop should fix this. https://github.com/casesandberg/react-color/blob/b89a69afb27166dda41ed81db9706eba8cfa35d8/src/components/common/EditableInput.js#L140

[davesnx]

Ops, that's true. I didn't read well the documentation.

But about changing state per props, seems that woudn't work. There's a componentWillReceiveProps that triggers this state change when the props and the state value are not equal. (I didn't tested).

[stevekinney]

It's strange though, because it doesn't seem to be a problem in the examples on the website.

[casesandberg]

The EdibleInput components only updates when you are not focused to prevent hex completion. For example, when you start to type in 333, the value that comes back is actually 333333, but we don't want to replace that in the field if you were meaning to type 333aaa.

I just looked at the demo you provided and see the issue you are talking about. I think the appropriate behaviour would be for the input to blur when you click or drag on anything outside of it. This would fix the issue you are talking about and update with the appropriate value.

[davesnx]

Exactly @casesandberg. Thanks for taking a look!

[rohan-deshpande]

Was just about to post about this, I think the behaviour is kind of odd right now. Take the Chrome picker as an example. If you have it open up on click, EditableInput immediately gets focus. If you change the saturation, it still has focus and the input doesn't update with the correct hex, even though the hex is changing and in fact the correct prop IS being passed down.

I don't think EditableInput should get focus unless you've clicked or tabbed into it and if you have clicked out of it, it should lose focus.

[casesandberg]

I agree the inputs should only hold focus when you are actually focused on them. I believe this an accessibility problem of the sliders not taking focus. I am looking into this for v3.0.0