View Issue Details

IDProjectCategoryView StatusLast Update
0017913phpList 3 applicationGeneralpublic21-06-18 14:03
Reportergingerling Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version3.2.2 
Summary0017913: hitting enter on compose pages clicks save as draft
DescriptionNotices this with the url checker on send a webpage where hitting enter is the natural response to try and trigger a second check. For example if your initial url was wrong and you got the error, you correct it and hit enter to trigger check or confirm you changed it etc.

It seems better to me that hitting enter should do save and continue editing or just go to the next box or what ever.

M referred to it as submitting the form, but really, it's not "a form" in peoples minds but one stage of many in a process which they (presumably) don't want to stop now by hitting enter
Steps To ReproduceGo to any box in sending process and hit enter
TagsUI Improvements

Activities

duncanc

19-12-15 14:52

updater   ~0057433

The way that the Enter key is processed is likely to be browser-specific, but will be either the first button on the page, or the next button after whichever input field you are in.

Using Firefox the Enter key always seems to save as draft regardless of the current input field. So this might be resolved simply by changing the order of the "Save as draft" and "Save and continue editing" buttons.

michiel

20-12-15 11:15

administrator   ~0057434

Yes, when that's done, it indeed changes the action.

http://stackoverflow.com/questions/925334/how-is-the-default-submit-button-on-an-html-form-determined

However, I wonder the effect this will have. Most users will now be used to the position of these buttons, and click without thinking. If we swap them, that may cause annoyances. That in comparison to those few people that might press enter when on a field, I'd say is not worth it.

Imagine an application you use a lot at once swapping the "save" and "delete" buttons in a dialog.

I tried changing the "tabindex" but that doesn't seem to make a difference. The only way we can deal with this is by catching the key-press with JS.