This was previously reported as T40042, fixed, then undone again via T42034.

This could be confusing since the summary text field looks like a multiline text input, possibly causing users to accidentally submit with incomplete summaries (which can't be corrected afterwards).

It could be interesting to try something else – maybe pressing Enter twice to submit the form, maybe Ctrl+Enter? We should probably do some research.

Three data points:

• Facebook: comments to posts on the timeline are normally single-line (pressing Enter in the text field submits a comment), but you can make them multi-line by pressing Ctrl+Enter or Shift+Enter (or by copy-pasting text with newlines). Pressing Enter submits the comment even if it is multi-line.
• My bank has these "wrapped single-line" inputs in some fields and pressing Enter always does nothing in them. Accidentally submitting a form could potentially have dire consequences there.
• My IM application (Miranda NG, not very popular and not necessarily user-friendly by default) normally behaves like Facebook (see above), but there are options for both of the other ideas I mentioned above:
  

For the advanced user, the current approach where enter adds new lines is counterintuitive. The advanced user not only knows that edit summaries cannot be multi-line, but it also feels wrong because they're also used to enter submitting their edit.

For the new user, the current approach feels misleading, as you're giving the user an expectation that edit summaries can be multi-lined when in fact they cannot. This user has no expectations about enter submitting the edit, so probably doesn't care too much about that.

I think the best approach would be to make the edit summary box single-line, and make enter submit the edit.

@Whatamidoing-WMF, you're right, this is related to T54133—enough so that I'm going to merge it as a duplicate. A text input (which WikiEditor uses for the edit summary) is submitted on enter by default, and a text area (which VE uses) shouldn't be submitted on enter for the usability reasons @matmarex pointed out.