-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
fix inputs not blurring when pressing enter #4692
Conversation
Signed-off-by: Andreas Schmidt <ndrscodes@gmail.com>
@@ -283,6 +283,9 @@ export class Input extends React.Component<InputProps, State> { | |||
} else { | |||
this.setDirty(); | |||
} | |||
|
|||
//pressing enter indicates that the edit is complete, we can unfocus now | |||
this.blur(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this happen a few lines up, after the this.setState()
call?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It depends. doing it like this, the user can unfocus the input even if it's not valid. If we blurred the input right after calling setState, the user would lose the ability to do so (even if trying to submit invalid data doesn't make much sense).. Idk which solution is better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this work with components like EditableList
? Have you tried that?
makes sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i've tested EditableLists using the accessible namespaces. The namespace is added and after that, the input blurs. Should we keep the input focussed in those cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the cleanest way of doing this in this scenario? Checking the type of Input in the onKeyDown method seems pretty unclean, but that would mean each class would have to decide if the input needs to be blurred itself, or needs to focus the input again. All of these solutions are not optimal imho
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I think EditableList
is the only place where this matters I would make a prop called something like blurOnEnter
with default value true
and then EditableList
can set it to false
.
Signed-off-by: ndrscodes <ndrscodes@gmail.com>
720f486
to
0d134ed
Compare
Signed-off-by: ndrscodes <ndrscodes@gmail.com>
66901b4
to
1f68b4a
Compare
sorry for causing trouble again. I removed an unnecessary call to stopPropagation(). @Nokel81 |
@ndrscodes Can you please investigate the namespace selector test that is failing? |
I've checked it, but i do not know what is causing this issue. It seems like the event is not being propagated to the Wizard/WizardStep. As soon as i implement this.blur() (even this.input.blur()), the WizardStep stops executing the next() function. Do you know what could be causing this? @Nokel81 |
What we could do is giving an onKeyDown handler to the |
That is a good idea |
3e08804
to
59af011
Compare
Signed-off-by: ndrscodes <ndrscodes@gmail.com>
59af011
to
3559fa9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. Thanks!
Fixes #4669.
This fix/feature causes inputs to blur (causing the onChange event to be triggered) once the Enter key is pressed. As of now, the user has to manually click outside of the active input in order to save the value.