Make a new talk page post with the new Discussion tool enabled in the Gadget preferences (Add topic)

Where exactly to find this? Please always include a full link - thanks!

Pressing just Enter will send the post if you've clicked on the "Subject" or "Summary" fields, is it possible that's what happened?

Also, pressing Ctrl+Enter will send the post if you've clicked anywhere within the tool.

This refers to talk page posts on Wikipedia. For example it happened here.

• Where is the Summary field?
• I don't think I clicked on Subject but there's a chance that this happened.
• In any case this also refers to pressing enter after clicking on the Subject field. This is not useful, not expected behavior, and only results in posts getting sent before they're ready. The same applies to ctrl+enter. The only way to post should be when the Add topic button is pressed (via mouse or via selecting it via the tab key and then pressing the enter key).

You also need to have already entered text in the body -- just hitting enter in the subject/summary won't do anything if there's no body to submit, which I think cuts down on the odds of premature submission.

Where is the Summary field?

Inside the (collapsed by default) "advanced" section.

@matmarex / @DLynch: do you recall what – if any – reason(s) led us to make it so ⏎ behaves differently depending on what field within the New Topic Tool you are focused within?

...instinctively, I think that ⏎ should behave the same in both fields.

@ppelberg We didn't do anything specifically about this, rather enter behaves consistently here with how it does in all HTML forms. (I.e. in multiline fields it adds a newline, otherwise it submits the form.) We can change that, but it's worth noting that it does depart from the generally expected behavior of the entire (browser) platform.

The explicit overrides we've done to standard behavior is to not submit the form if it doesn't pass validation (though technically you can also do that within HTML attributes; we're just doing it in JavaScript instead), and adding the meta-enter behavior to submit the form from within the multiline field.

In T326500#8532536, @DLynch wrote:

@ppelberg We didn't do anything specifically about this, rather enter behaves consistently here with how it does in all HTML forms. (I.e. in multiline fields it adds a newline, otherwise it submits the form.) We can change that, but it's worth noting that it does depart from the generally expected behavior of the entire (browser) platform.

! In T326500#8532539, @DLynch wrote:

The explicit overrides we've done to standard behavior is to not submit the form if it doesn't pass validation (though technically you can also do that within HTML attributes; we're just doing it in JavaScript instead), and adding the meta-enter behavior to submit the form from within the multiline field.

This context is helpful – thank you for walking me through it, @DLynch. I'm curious to hear what Nico thinks about this...

@nayoub: a question for you about keyboard shortcuts and the New Topic Tool...

Below is a current mapping of the keyboard shortcuts people can use to publish a new topic using the New Topic Tool on desktop. Can you share what – if any – risks you can see by modifying the behavior to what's shown in the proposed section?

As mentioned above, this was deliberately implemented to mimic the behaviour of single line inputs.

This is also how it works in the 2010 WTE, which also has a "new topic" mode (?section=new). Users familiar with those interfaces may expect to be able to press just enter in the subject field, or the edit summary field (under "Advanced" in our tools).

Given that you would have to fill out the body field first before pressing enter in the subject field would do anything, I don't think there is a high risk here of people accidentally submitting.

To remove the special handling of single line fields (and make them require ctrl+enter) is a trivial to fix, but we may end up with complaints either way.

(The trivial fix is to remove isMultiline from https://github.com/wikimedia/mediawiki-extensions-DiscussionTools/blob/0ef532149b00e10b0395493188583c723c71dfad/modules/dt.ui.ReplyWidget.js#L751, and maybe cleanup the now unused bound function argument)

Change 957276 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/DiscussionTools@master] Require CTRL+Enter to submit a comment, regardless of the input

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

With the above patch you now need to press CTRL+Enter to submit your comment when you have a single-line input focused, such as "Subject" or "Summary" (in advanced).

I’m not sure if disabling plain Enter in the edit summary field is a good idea. The difference between the topic title and the edit summary is that the topic title is likely entered at or near the beginning of the drafting process, when intentionally pressing Enter to post the topic is unlikely, while the edit summary is likely entered at the end of the drafting process, when pressing the Enter key is more likely intentional than unintentional.

I'm of two minds there, just because the edit summary really looks like it's multiline, so I wouldn't judge anyone who forgot that in the moment and wound up accidentally submitting their edit early. I do agree it's also more likely to be the place where someone is done with their edit and just wants to submit, though.

Perhaps we could duplicate the same UI hint that's in the VE save dialog, that appears only after you press enter while inside the summary input?

(The DT one looks less multiline than the VE one, at least. Something about the spacing on it and the prefilled comment taking up so much space always gives me this gut feeling that it's multiline, though. It could just be me...)

In T326500#9166623, @DLynch wrote:

I'm of two minds there, just because the edit summary really looks like it's multiline

In T326500#9166625, @DLynch wrote:

(The DT one looks less multiline than the VE one, at least. Something about the spacing on it and the prefilled comment taking up so much space always gives me this gut feeling that it's multiline, though. It could just be me...)

The DT one doesn’t look multiline at all for me, but that also could be just me. The VE one indeed looks and is multiline. Once I type a summary that’s longer than one line, it becomes crystal clear that the VE one is a multiline <textarea>, while the DT one is a single-line <input type="text">:

VisualEditor	Reply tool

(By the way, it looks like no one tested writing a long edit summary while being logged out, the number of characters left overlaps with the disclaimer text…)

In T326500#9166623, @DLynch wrote:

so I wouldn't judge anyone who forgot that in the moment and wound up accidentally submitting their edit early. […]

Perhaps we could duplicate the same UI hint that's in the VE save dialog, that appears only after you press enter while inside the summary input?

If it’s really more than just you, that would be a strong reason to disable saving with Enter in the summary field. In this case, this reminder would be nice (maybe in the title field as well, especially now that it has just been changed and people’s muscle memories still want to press Enter).

In think we should proceed with requiring ctrl+enter and if we get feedback that users are expecting enter to work on the edit summary field (which is very rarely used anyway) we can reconsider.

I expect Enter to work on the edit summary field, although I’m only one user, not “users”. 😉 So okay, require Ctrl+Enter until/unless others join me, but please do add the warning @DLynch proposed in T326500#9166623.

Change 957276 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Require CTRL+Enter to submit a comment, regardless of the input

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

In T326500#9172956, @Tacsipacsi wrote:

but please do add the warning @DLynch proposed in T326500#9166623.

Change 958993 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Show a hint for ctrl-enter for comment submission if just enter is used

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

In T326500#8545690, @ppelberg wrote:

In T326500#8532536, @DLynch wrote:

@ppelberg We didn't do anything specifically about this, rather enter behaves consistently here with how it does in all HTML forms. (I.e. in multiline fields it adds a newline, otherwise it submits the form.) We can change that, but it's worth noting that it does depart from the generally expected behavior of the entire (browser) platform.

! In T326500#8532539, @DLynch wrote:

The explicit overrides we've done to standard behavior is to not submit the form if it doesn't pass validation (though technically you can also do that within HTML attributes; we're just doing it in JavaScript instead), and adding the meta-enter behavior to submit the form from within the multiline field.

This context is helpful – thank you for walking me through it, @DLynch. I'm curious to hear what Nico thinks about this...

@nayoub: a question for you about keyboard shortcuts and the New Topic Tool...

Below is a current mapping of the keyboard shortcuts people can use to publish a new topic using the New Topic Tool on desktop. Can you share what – if any – risks you can see by modifying the behavior to what's shown in the proposed section?

Cursor focus	Subject field empty	Description field empty	CURRENT shortcut required to publish new topic	PROPOSED shortcut required to publish new topic
Subject field	No	Yes	N/A; not able to publish new topic using shortcut when Description field is empty	---
Subject field	No	No	⏎	⌘ + ⏎
Description field	Yes	No	⌘ + ⏎	---
Description field	No	Yes	N/A; not able to publish new topic using shortcut when`Description` field is empty	---

@ppelberg: It seems for the scenario mentioned in the fourth row on the table you created, if I press ctrl-enter five times it publishes the new topic without any description.

https://en.wikipedia.org/wiki/User_talk:RYasmeen_(WMF)/sandbox#non-empty_subject_field_2

Change 958993 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Show a hint for ctrl-enter for comment submission if just enter is used

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

@DLynch Right now the hint for pressing ctrl-enter for comment submission "You can press ⌘⏎ to submit your comment" is showing up when enter is used for cases where we are not allowing submitting comment, such as: when Description field is empty and the cursor is either on Subject field or the summary field. I wonder if it would be considered misleading?

I'm unsure. I think it's enough of an edge case that it shouldn't be too confusing -- other error messages will still appear. Let's see if we get any feedback complaining about it, I guess.

I also unexpectedly get the hint when trying to add a link in visual mode, and pressing Enter while inside the link inspector.

Okay, that one should get fixed!

✅ Talk pages sends posts when you press Cmd+Enter while pressing Enter adds a new line as expected but it still shows the hit as mentioned by Rummana. I don't think the fix for that is up yet.

Change 968296 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] ReplyWidget: don't show the enter hint if the target was in bodyWrapper

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

Change 968297 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] ReplyWidget: don't show the enter hint if the reply button is disabled

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

Change 968296 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] ReplyWidget: don't show the enter hint if the target was in bodyWrapper

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

Change 968297 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] ReplyWidget: don't show the enter hint if the reply button is disabled

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

@ppelberg: It seems for the scenario mentioned in the fourth row on the table you created, if I press ctrl-enter couple times it publishes the new topic without any description.

https://en.wikipedia.org/wiki/User_talk:RYasmeen_(WMF)/sandbox#non-empty_subject_field_2

This is still happening and also the hint is showing up when there is just an empty line in the description field.

@Ryasmeen the description field isn't empty -- you're adding a linebreak to it, otherwise it wouldn't have let you post the topic. (We could argue about whether we should count an all-whitespace description is being empty, of course, but as it stands there is content in it.)

@DLynch: Could you provide a valid workflow where all-whitespace description will be counted as non-empty?

@Ryasmeen fair point -- I was thinking it was something we had allowed for backwards-compatibility with the behavior of the non-DT new-topic tool, but I checked and that does suppress entirely-whitespace comments.

It's not really an issue related to this ticket per se, since it's not specific to the send-via-enter method, so I'll make a new task about it.

Hm, actually... it's different from the classic editor because we auto-sign the comments, so it's impossible to leave an actually completely empty comment/topic. And the classic new-topic editor would certainly allow the equivalent of just entering "~~~~".

So, a possible reason to leave such a topic/comment would be a "sign here" workflow.

I made T351470 for this question.

In T326500#9339232, @DLynch wrote:

Hm, actually... it's different from the classic editor because we auto-sign the comments, so it's impossible to leave an actually completely empty comment/topic. And the classic new-topic editor would certainly allow the equivalent of just entering "~~~~".

So, a possible reason to leave such a topic/comment would be a "sign here" workflow.

Thanks @DLynch for the explanation and for creating a separate ticket for further discussion. Yeah, if we want to support the "sign here" workflow and it is not really specific to this change, we can close this one.