This may very well be a "won't fix", but I thought it was worth documenting. The following tests were done with Firefox (I haven't tried with other browsers):
In Drupal 6, pressing the "enter" key in one of the input fields on the node submission page either
(a) submits the node, or
(b) does nothing
(On some forms it does "a", on some forms it does "b"... I can't figure out exactly what controls the behavior.)
In Drupal 5, the behavior was a bit different:
(a) previews the node, or
(b) does nothing
It looks like the change between Drupal 5 and 6 is due to http://drupal.org/node/195678 which puts the "save" button out in front on submission forms.
The behavior in Drupal 6 is not great, in my opinion -- people have a tendency to hit "enter" by mistake, and submitting the node (rather than previewing it) seems like it will lead to a lot of half-finished nodes being submitted on Drupal 6 sites. Also, ideally the behavior would be standardized for all forms.
I don't really know how to fix this at all, though. I did some Googling, and the solutions out there all seem really hackish (adding a preview button out in front and hiding it from display using CSS... blech).
Comments
Comment #1
Frank Ralf CreditAttribution: Frank Ralf commentedMy current installation of D7 doesn't let me use the enter key anymore in textarea fields to create multi-line entries. It did work yesterday (see screencast http://drupal.org/node/467296#comment-2095248 ).
This might be a feature to prevent un-intentional submission of a form but it steals the enter key for any other purpose like scripting for accessibility (see #467296: Accessibility improvements for vertical tabs ) which I would deem a bug.
Frank
Comment #2
matt_harrold CreditAttribution: matt_harrold commentedTesting Drupal 7 with latest .dev release (9th October) ... enter key does not work in the body field, the summary field ... and AFAIK ... all other textareas.
Comment #3
Frank Ralf CreditAttribution: Frank Ralf commentedMy suspect would be the following snippet from /misc/ajax.js (line 165 ff). AFAICS it's the only relevant reference to the enter key (keycode = 13) I found in core files:
EDIT:
Seems to be the culprit. Deactivating this function temporarily by changing it to keyCode == 913 reinstates the usual behavior.
hth
Frank
Comment #4
Frank Ralf CreditAttribution: Frank Ralf commentedChanged issue title to reflect the current problem at hand and priority to "critical".
Comment #5
Frank Ralf CreditAttribution: Frank Ralf commentedSeems to be fixed. I'd be curious what caused the problem. There have been some recent changes to includes/ajax.inc but I can't figure out what's going on there exactly.
Comment #6
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis is still a valid issue. I would vote to disable the enter key in all textfields.
Comment #7
Frank Ralf CreditAttribution: Frank Ralf commented@Damien
I am skeptical whether this is a good idea.
AFAIK disabling the enter key in all textfields can have one of two purposes:
1) Prevent accidental submission of a form.
Using the enter key for form submission is also an accessibility/usability issue because forms should be usable without using a mouse.
2) Preventing line breaks
This should be handled by a filter not by disabling the enter key.
Cheers,
Frank
Comment #8
carlos8f CreditAttribution: carlos8f commented@Frank
I created #631334: Enter key disabled by ajax.js, making it impossible to use textareas properly which focuses on the bug you described. I think this issue (standardize submission behavior) is valid though and I support Damien's idea. I suspect he meant textfields as in #type=textfield, because hitting enter inside a textarea has no effect on form submission.
Comment #9
Frank Ralf CreditAttribution: Frank Ralf commented@carlos8f
Thanks for your input. Perhaps we should mark one of the treads as a duplicate?
Just a short general hint: The recommended method for disabling the submit behavior of the enter key is using the DOM method event.preventDefault which jQuery does a good job of making this working across browsers.
Cheers,
Frank
Comment #10
carlos8f CreditAttribution: carlos8f commentedNo reason to mark a duplicate. I created the new issue for ajax.js to prevent issue hijacking, because I think David Rothstein brought up something that should be addressed at some point. The ajax.js issue is a pretty bad usability flub though, because how are we supposed to write articles when we're stuck with one big paragraph :)
Comment #11
Frank Ralf CreditAttribution: Frank Ralf commentedYou're right. Perhaps I should move my stuff over to your thread ;-)
Comment #12
Everett Zufelt CreditAttribution: Everett Zufelt commentedBumping to D8. Not sure if there is still an issue here, but if there is it doesn't need to be dealt with in D7.
Comment #13
jhedstromGiven we have no automated js testing, I think this may be too disruptive for 8.0.x, tentatively bumping to 8.1.x.
Comment #14
Frank Ralf CreditAttribution: Frank Ralf commentedJFTR, we had an extensive discussion about the use of the Enter key while working on #467296: Accessibility improvements for vertical tabs for Drupal 7. Please read our rationale in the following comments and take that into account when considering changes to the Enter key behavior in forms:
Kind regards,
Frank