Confirming context menu entries via Enter when entering comments triggers comment to be posted

Question 1

related: Pressing Enter in comment box unexpectedly submits form

While I'm not basically against this feature, it is annoying to press Enter from the context-menu (e.g. when verifying my spelling via FF, or pasting older clipboard entries via ClipX) and realize that not only the effect I wanted (spelling correct, older entry pasted) occurs, but also my unfinished comment is posted.

(Please say this is not status-bydesign)

Question 2

This doesn't happen in Chrome 6. It does occur in IE7 and FF 3.6

Question 3

Oh, you're just tempting Jeff, Tobias.

Question 4

Ok, so this may be a bug in FF and IE then... does anyone know some workaround then? apart from mouse clicking?

Question 5

@Tobias - Can't you use the keyboard shortcuts?

Question 6

@Barry: which ones? For ClipX yes, but for spelling correction, the correction suggestions don't have any

Question 7

Not reproducible, Firefox 4 on Mac (yes, beta, I know).

Question 8

Curiously, pressing Enter in the address bar when you've typed a javascript: URL that contains an error also submits the comment (at least in Firefox).

Question 9

I was just about to report the same bug, when I was pointed here. This is FF3.6.11 on Windows, and I'm seeing the same: My spillchucker underlines a word, I move the cursor back there, press Shift+F10 to bring up the context-sensitive menu, pick the right entry, hammer the Enter key, and type on, but my comment has just been committed. Very annoying.

Question 10

I can confirm this bug hit me several times in FF4b7 on Linux. I'm too tired to look into this now, but I suspect a keydown event is issued when pressing Enter anyway, even in a context menu.

Question 11

there should be a difference when pressing <kbd>Enter</kbd> on contextMenu and just Enter after typing. Confirmed with spelling checker contextMenu Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0E)

Question 12

In case you meant to clarify this question and ensure people who have issues using much more popular clipboard managers like Ditto find it too, don't bother; that reportedly "deviates from the original intent of the post".🙄

Question 13

It appears that the cause of this bug is the same as for Pressing <Enter> in an input method editor should not submit comments, which affects IME users on various browsers, not just Firefox.

In both cases, the problem is that the event handler that the Stack Exchange UI uses to trigger comment form submission via the Enter key is, for some peculiar reason, set to trigger on the keyup event rather than, as one would expect, on the keydown event.

The problem here is that, if pressing Enter causes focus to transfer from some other UI element (such as a context menu) to the comment entry field, then the keyup event will be dispatched to the textarea, rather than to whatever element previously had the focus (which might not even exist anymore). This is, in fact, correct behavior, according to the W3C UI Events specification:

Note: The event target might change between different key events. For example, a keydown event for the Tab key will likely have a different event target than the keyup event on the same keystroke.

(Actually, I recall seeing a much more explicit note about this behavior somewhere, but I can't track it down right now.)

Anyway, the right way to fix this is simply to attach the handler to the keydown event instead. If that event fires on the textarea, we can be sure that the user actually did press the key while the focus was in the textarea.

In fact, while waiting for a proper fix from the SE devs, I've implemented a fix for this issue in the Stack Overflow Unofficial Patch using the following code:

StackExchange.helpers.submitFormOnEnterPress = function ($form) {
 var $txt = $form.find('textarea');
 $txt.keydown(function (event) {
 if (event.which === 13 && !event.shiftKey && !$txt.prev("#tabcomplete > li:visible").length) {
 $form.submit();
 }
 }).keypress(function (event) {
 // disable hitting enter to produce a newline, but allow <shift> + <enter>
 return event.which !== 13 || event.shiftKey;
 });
};

This overrides the built-in SE code to enable submit-on-enter behavior in the comment editor, replacing it with a modified version that reacts to keydown events instead of keyup events. As far as I can tell, this fixes the issue described above, and also allows IMEs to work properly without requiring any composition event tricks.

Question 14

Awesome analysis! Also, I didn't know about SOUP, definitely worth checking out

Question 15

I am not supporting this answer because I am too skeptical of your analysis of the specification. If this is specified, it seems to prohibit Gecko's behavior: "This event type MUST be dispatched before the beforeinput, input, and keyup events associated with the same key."

Question 16

@PhilippeCloutier: The sentence you quote specifies when the event must be dispatched. It does not say it must be dispatched to the same target as those later events associated with the same keypress. (Often it will be, since keyboard focus does not often move during a keypress. But sometimes that can happen, and the tab and enter keys in particular quite often trigger a focus change.)

Question 17

@IlmariKaronen: I do understand that edge case; what I am questioning is your interpretation of the spec. It does not say the target, but by specifying that they must be dispatched before, it implicitly specifies that they must also be dispatched (regardless of the target). Yet in your interpretation, there are cases where a keyup would have no associated keydown.

Question 18

@PhilippeCloutier: You seem to be looking at things from the perspective of a single event target. I'm pretty sure the W3C spec isn't written from that perspective. Just because the keydown and keyup events have different targets doesn't mean one of them isn't dispatched. But it does mean that a listener attached to a specific DOM element may only see one of them. (If you want to see both, attach your event listener to window. That should work, at least unless the focus moves into or out of the browser window entirely. I'm not 100% sure how that edge case is supposed to be handled.)

Question 19

@IlmariKaronen: Precisely... you seem to be assuming that Enter is pressed while the focus is in the browser, while what brought me here is a comment submitted while I pasted a clip from Ditto. Although the phrasing is awkward at best (comparing an event type with events), it seems to indicate Gecko violates the spec, which is why I am still not supporting this answer.

Question 20

For whatever reason, Firefox doesn't block the chrome-initiated keyup event from being propagated after it returns focus to the document. My guess would be that it acts on the keypress event, switches back to the document context, and never kills the event chain in the process. I personally believe that it's buggy behaviour and should probably be reported to the Firefox developers as such.

However, it seems to be only the keyup event (at least in Firefox) that gets sent, so it's possibly to work around that issue by reassigning the comment submit handler from keyup to keydown. This seems to prevent the accidental submissions while maintaining the desired functionality without breaking anything else.

I've quickly mocked this swap up in this userscript for the purposes of demonstration. If anyone would like to independently verify that making the change fixes the problem and doesn't seem to cause issues elsewhere, feel free. I'm not sure whether or not it would fix the problem in IE7, but if I remember correctly from trying to replicate this in various browsers, it's already a non-issue in IE8.

Question 21

+1 Your script works partly - unfortunately it also blocks posting via Enter

Question 22

@TobiasKienzler Oh, whoops. I was being stupid about rebinding the handler, fixed - it should actually post now too, heh.

Question 23

Does anyone have a Mozilla bug# for this? it should be fixed, after all...

Question 24

@Fowl Hmm, I'm unable to find an open bug. Looks like there was a similar report, but they seem to have fixed the problem for that particular use case. This is certainly still an issue in the current release, though. I'm a little surprised that whatever change was made to address the other case didn't fix this one as well.

Question 25

@TimStone filed as bugzilla.mozilla.org/show_bug.cgi?id=771411

Question 26

Years later, and the bug is still present...

Question 27

I concur with Tim. This is a bug in Firefox, not us.

Doesn't happen in: Safari, Chrome, Opera, IE.

Question 28

I agree with you regarding this is a bug in Firefox, but don't we try to work around issues like these all the time, especially in IE? E.g., you don't say that the event handler model is broken in IE, because it doesn't/didn't support AddEventListener.

Question 29

@marcel no, we stopped supporting IE6 and barely support IE7 (eg we only guarantee basic functionality on IE7, but the site may look and work wrong in some edge cases)

Question 30

Fun fact: Chrome/OS X: Unfinished comments get posted when leaving page by manually entering URL.

Ilmari Karonen 32k5 gold badges93 silver badges168 bronze badges · Accepted Answer · 2014-01-25 21:21:01Z

It appears that the cause of this bug is the same as for Pressing <Enter> in an input method editor should not submit comments, which affects IME users on various browsers, not just Firefox.

In both cases, the problem is that the event handler that the Stack Exchange UI uses to trigger comment form submission via the Enter key is, for some peculiar reason, set to trigger on the keyup event rather than, as one would expect, on the keydown event.

The problem here is that, if pressing Enter causes focus to transfer from some other UI element (such as a context menu) to the comment entry field, then the keyup event will be dispatched to the textarea, rather than to whatever element previously had the focus (which might not even exist anymore). This is, in fact, correct behavior, according to the W3C UI Events specification:

Note: The event target might change between different key events. For example, a keydown event for the Tab key will likely have a different event target than the keyup event on the same keystroke.

(Actually, I recall seeing a much more explicit note about this behavior somewhere, but I can't track it down right now.)

Anyway, the right way to fix this is simply to attach the handler to the keydown event instead. If that event fires on the textarea, we can be sure that the user actually did press the key while the focus was in the textarea.

In fact, while waiting for a proper fix from the SE devs, I've implemented a fix for this issue in the Stack Overflow Unofficial Patch using the following code:

StackExchange.helpers.submitFormOnEnterPress = function ($form) {
 var $txt = $form.find('textarea');
 $txt.keydown(function (event) {
 if (event.which === 13 && !event.shiftKey && !$txt.prev("#tabcomplete > li:visible").length) {
 $form.submit();
 }
 }).keypress(function (event) {
 // disable hitting enter to produce a newline, but allow <shift> + <enter>
 return event.which !== 13 || event.shiftKey;
 });
};

This overrides the built-in SE code to enable submit-on-enter behavior in the comment editor, replacing it with a modified version that reacts to keydown events instead of keyup events. As far as I can tell, this fixes the issue described above, and also allows IMEs to work properly without requiring any composition event tricks.

Awesome analysis! Also, I didn't know about SOUP, definitely worth checking out
I am not supporting this answer because I am too skeptical of your analysis of the specification. If this is specified, it seems to prohibit Gecko's behavior: "This event type MUST be dispatched before the beforeinput, input, and keyup events associated with the same key."
@PhilippeCloutier: The sentence you quote specifies when the event must be dispatched. It does not say it must be dispatched to the same target as those later events associated with the same keypress. (Often it will be, since keyboard focus does not often move during a keypress. But sometimes that can happen, and the tab and enter keys in particular quite often trigger a focus change.)
@IlmariKaronen: I do understand that edge case; what I am questioning is your interpretation of the spec. It does not say the target, but by specifying that they must be dispatched before, it implicitly specifies that they must also be dispatched (regardless of the target). Yet in your interpretation, there are cases where a keyup would have no associated keydown.
@PhilippeCloutier: You seem to be looking at things from the perspective of a single event target. I'm pretty sure the W3C spec isn't written from that perspective. Just because the keydown and keyup events have different targets doesn't mean one of them isn't dispatched. But it does mean that a listener attached to a specific DOM element may only see one of them. (If you want to see both, attach your event listener to window. That should work, at least unless the focus moves into or out of the browser window entirely. I'm not 100% sure how that edge case is supposed to be handled.)
@IlmariKaronen: Precisely... you seem to be assuming that Enter is pressed while the focus is in the browser, while what brought me here is a comment submitted while I pasted a clip from Ditto. Although the phrasing is awkward at best (comparing an event type with events), it seems to indicate Gecko violates the spec, which is why I am still not supporting this answer.

Stack Exchange Network

Confirming context menu entries via Enter when entering comments triggers comment to be posted

3 Answers 3

You must log in to answer this question.

Linked

Hot Network Questions

Confirming context menu entries via Enter when entering comments triggers comment to be posted

3 Answers 3

You must log in to answer this question.

Linked

Related

Hot Network Questions