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
Hitting enter in text fields triggers metadata form save #7895
Comments
|
Well, our researchers have flagged this as a real problem. Apparently they have the (pesky) habit of hitting the enter key when filling in the metadata form. What we observe that happens is that there is no validation message, but the form is reset and any fields that have been filled in previously are cleared. And it is especially that last part that annoys them a lot. If only there would be the same validation warning message as when hitting the save button and the form's data would be retained, this would be acceptable. Note that this only happens when creating a new dataset, not when editing an existing dataset. We are running Dataverse 5.5 on Payara 5.20213 |
@djbrooke can you confirm if it is still resetting all the fields after hitting return, because it seems that fields are retained in 5.7? I am asking because in the forum discussion on October 1th you confirm the behaviour. Not wiping the field seems the most important thing to fix. Would be nice, though, if the enter is not triggering a form submit when focus i inside a text input field. Better behaviour could be to set focus (jump) to the next field? |
@PaulBoon - What I see now on demo.dataverse.org/v5.7 is that entering a single line text value and hitting enter on the dataset create page just resets the whole form, whereas doing the same thing when editing the metadata on an existing draft dataset saves the form and the new value, returning you to the dataset view. |
Just discovered that things are different when using Safari, which I do. When using FireFox or Chrome I do indeed see the problems when creating a dataset on Dataverse demo.dataverse.org v. 5.7 build 643-80fda20 (this morning). |
I second @PaulBoon's comment that fields need to not clear, and "enter" function should move focus to the next field, in all cases. |
I agree on the fact that the form should not be cleared. But I do not agree to the enter key moving focus to the next field. Since the beginning of the web forms, hitting enter by default submits the form. Jakob Nielsen's first law of the Internet: Dataverse should behave the same way as most web apps do. Instead, a proper validation message should popup stating that some fields are missing or have wrong data and urges the user to fix these values when submission fails. Just my € 0.02 |
Thanks for the comment, @Kris-LIBIS. While it has been in a standard, current behavior of "enter" on form fields is variable and determined by context. Validation is a reasonable option. We are hearing regularly that users are hitting enter and unintentionally clearing fields on the form. |
Hey everyone, we are also experiencing this problem more and more. Is there already a plan whether the issue will be included in one of the next releases? |
@yvgrossmann to get a sense of what we're working on, please check out our board at https://github.com/orgs/IQSS/projects/2 . No, this issue has not been prioritized. That said, we are very open to pull requests! Thanks for taking the time to leave a comment. |
@yvgrossmann we went ahead and put this on the board - you can see it in Up Next. Like @pdurbin if you would like to work on it and contribute before we get to it, that's great too, just let us know. :) |
In at least 5.4.1+ - hitting enter when editing a single-line text metadata field results in the whole from being saved. In create mode/when required fields are not filled out, this appears to result in a failed save with the validation message appearing (as it does if you hit the Save button). (tested on v5.5 demo.dataverse.org and on a 5.4.1 test instance. I did not check earlier versions.)
I'm not sure how/when this started but I'd suspect some change that either added a handler for those fields or some change to the Javascript being run (returning false stops default handlers from running, so if some change stopped a 'return false;' it might have triggered this issue.)
The text was updated successfully, but these errors were encountered: