This is intentional to prevent users accidentally submitting as the input is multi-line, see T106325. CTRL+Enter in any dialog will trigger the primary action, so that can be used, but we could add a message to make that obvious. Maybe we could flash it up when the user presses Enter as that currently does nothing.

I noticed that Chrome did this for a few releases when they got rid of backspace-to-go-back -- when you pressed Backspace, it would pop up a little notice saying "Press Ctrl+Backspace to go back". Personally I felt it was an admission that users would be confused without actively helping them... Given that we're talking about replacing the input with a word-wrapped single-line thing with auto-complete (somehow), maybe we could make this work?

Most forms on the Internet allow for the return key being hit, and in fact the default for several forms which allow a distinction between multi/single line (e.g. Facebook Messenger) is that return submits the form and shift+return (choose a modifying key as desirable depending on the application in question) provides for new lines. I agree that new lines should be impossible, but I don't see rationale for why that implies that I shouldn't be able to use the return key to submit the form.

Can I get help on the train of thought there?

Can I get help on the train of thought there?

Train of thought is basically:

1. it looks like a multi-line edit area.
2. as such, people trying to press enter for a newline is very plausible
3. if that happens, submitting the form would explicitly be cutting off the user's edit, only partially completed
4. you can't go back and edit the summary of your edit later, so that would be very annoying to someone who was trying to write a detailed summary

Note that many of the places where the default is to submit-on-enter are places where you can edit what you just did, or where you're adding to an ongoing conversation, so sending another message in just a second with the rest of your statement isn't really breaking stuff up.

As Ed said, we do have cmd/ctrl-enter as a shortcut for this already, in any OOUI dialog window, so making that more discoverable in some way might make sense. I'm not sure what would be best -- as James said, the UI experience of that Chrome popup was very much "we know what you want, but we're not going to do it, nyaaah".

In this particular case, we could maybe treat hitting enter in that field as equivalent to hitting tab -- move your focus on to the next element (the "minor edit?" checkbox), so it doesn't just inexplicably ignore you? Doesn't solve the discoverability issue, but it does perhaps make people feel less frustrated about just nothing happening.

From the POV of a person who has never seen a history page, the deep box in the Save dialog makes it look like newlines/multi-paragraph edit summaries are possible (and possibly even encouraged). Unlike wiki pages, edit summaries can' t be changed. So when editors are trying to provide detailed edit summaries (a strongly encouraged behavior), then they might try something like this:

1) I fixed a typo
2) I removed a dead link

It looks perfectly reasonable in the UI. But if hitting Return saves the page, then they'll never be able to type the second part.

In T153241#2874964, @Esanders wrote:

This is intentional to prevent users accidentally submitting as the input is multi-line, see T106325.

I understand, but this restriction should be applied only to the summary field. Hitting return key when focus is on minor/watch checkboxes should work as in OWE at least.

In T153241#2877462, @DLynch wrote:

In this particular case, we could maybe treat hitting enter in that field as equivalent to hitting tab -- move your focus on to the next element (the "minor edit?" checkbox), so it doesn't just inexplicably ignore you? Doesn't solve the discoverability issue, but it does perhaps make people feel less frustrated about just nothing happening.

This is a good idea. If user hits return key, the focus moves to the minor checkbox (as if user hit tab key) and if user hits return key again, form will be submitted (and changes saved). These two checkboxes are already designed in OOUI, therefore they are highlighted enough when getting a focus and therefore it is noticeable, what the return key just did (simulated tab key).

In T153241#2875085, @Jdforrester-WMF wrote:

I noticed that Chrome did this for a few releases when they got rid of backspace-to-go-back -- when you pressed Backspace, it would pop up a little notice saying "Press Ctrl+Backspace to go back". Personally I felt it was an admission that users would be confused without actively helping them...

This is the last possibility if nothing other would work, but still a good idea. If user hits return key and then nothing happens or happens something unexpected to him/her (no newline and no submit/save action), (s)he should be aware of why it didn't work as (s)he expected. In this case, simple popup would do.

In T153241#2877462, @DLynch wrote:

Train of thought is basically: [snip]

Okay, that's helpful rationale for the current state. Why was the fix "remove enter" and not "make the area look like a single-line edit area"? "OOUI" again?

@Dvorapa

I understand, but this restriction should be applied only to the summary field. Hitting return key when focus is on minor/watch checkboxes should work as in OWE at least.

I think that would be unfortunately inconsistent behavior.

Generally: I'll get used to ctrl + enter if nothing changes, but I'm doubtful I'll be the only one grumbling. :)

In T153241#2880751, @Izno wrote:

Okay, that's helpful rationale for the current state. Why was the fix "remove enter" and not "make the area look like a single-line edit area"? "OOUI" again?

When you run out of space in a single-line textfield (a <input type=text> in HTML), you get a fairly unpleasant interface, with no scrollbars and no obvious indication that there is more text there. You can only access the offscreen text by arrow keys, or making a selection with mouse. So, to display scrollbars, we're currently using a <textarea> and preventing the user from inputting newlines into it.

This problem affects the old wikitext editor as well (depending on the text and the screen resolution, there is visual space for about 100-200 characters, maximum allowed length is currently 255 bytes and hopefully about to increase per T6715). But it would be even worse in VisualEditor, since the edit summary field in VE's save dialog is narrower, fitting ~70 characters.

Perhaps we could do some logging with EventLogging to see what people are trying to use the Enter key in the edit summary for? We could log the contents of the edit summary field when the user presses Enter (which currently does nothing), and one more time when they try to save the edit.

• If the final saved edit has the same summary as the one we logged on the Enter press, the user probably meant to save the edit with Enter.
• If the final saved edit has different summary from the one we logged on the Enter press, the user probably meant to insert a newline with Enter.

Perhaps we'll discover that one of these is more common, and it will be obvious which is the correct solution. (Or perhaps we won't, but it might we worth trying.)

In T153241#2880751, @Izno wrote:

Why was the fix "remove enter" and not "make the area look like a single-line edit area"? "OOUI" again?

This time the answer is "User testing". The big box is more likely to get used.

In T153241#2881245, @matmarex wrote:

Perhaps we could do some logging with EventLogging to see what people are trying to use the Enter key in the edit summary for?

Great idea! :)

In T153241#2881198, @matmarex wrote:

When you run out of space in a single-line textfield [snip]

Okay, this makes sense.

In T153241#2881784, @Whatamidoing-WMF wrote:

This time the answer is "User testing". The big box is more likely to get used.

Please provide said user testing results (or a link to such or similar).

In T153241#2881245, @matmarex wrote:

Perhaps we could do some logging with EventLogging

Excellent suggestion!

Does anybody started the user testing/logging to see, what users actually do?

In T153241#2909616, @Dvorapa wrote:

Does anybody started the user testing/logging to see, what users actually do?

I don't think so. This would be a non-trivial undertaking, and I'm not really sure if it would be worth it.

In T153241#2874964, @Esanders wrote:

CTRL+Enter in any dialog will trigger the primary action, so that can be used, but we could add a message to make that obvious. Maybe we could flash it up when the user presses Enter as that currently does nothing.

I think for now, it would be good to at least do this.

Change 335224 had a related patch set uploaded (by Bartosz Dziewoński):
ve.ui.MWSaveDialog: Show a hint to use Ctrl Enter to submit when pressing Enter

https://gerrit.wikimedia.org/r/335224

Change 335224 merged by jenkins-bot:
ve.ui.MWSaveDialog: Show a hint to use Ctrl Enter to submit when pressing Enter

https://gerrit.wikimedia.org/r/335224