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 )

  • This doesn't happen in Chrome 6. It does occur in IE7 and FF 3.6 Oct 5 '10 at 7:32
  • Oh, you're just tempting Jeff, Tobias. Oct 5 '10 at 7:44
  • Ok, so this may be a bug in FF and IE then... does anyone know some workaround then? apart from mouse clicking? Oct 5 '10 at 7:50
  • @Tobias - Can't you use the keyboard shortcuts? Oct 5 '10 at 7:57
  • 2
    @Barry: which ones? For ClipX yes, but for spelling correction, the correction suggestions don't have any Oct 5 '10 at 8:08
  • Not reproducible, Firefox 4 on Mac (yes, beta, I know).
    – kennytm
    Oct 5 '10 at 8:39
  • 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).
    – bobince
    Oct 5 '10 at 16:30
  • 1
    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.
    – sbi
    Oct 24 '10 at 14:02
  • 1
    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. Nov 19 '10 at 0:23
  • 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)
    – serhio
    Nov 20 '10 at 22:32

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 textarea, 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 DOM 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) {
    }).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 Jan 26 '14 at 8:49

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.

  • +1 Your script works partly - unfortunately it also blocks posting via Enter Nov 29 '10 at 12:21
  • @TobiasKienzler Oh, whoops. I was being stupid about rebinding the handler, fixed - it should actually post now too, heh.
    – Tim Stone
    Nov 29 '10 at 13:19
  • Works perfect now, thanks :) Nov 30 '10 at 9:05
  • Does anyone have a Mozilla bug# for this? it should be fixed, after all...
    – Fowl
    Jul 6 '12 at 1:35
  • @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.
    – Tim Stone
    Jul 6 '12 at 2:29
  • 1
    @TimStone filed as bugzilla.mozilla.org/show_bug.cgi?id=771411
    – Fowl
    Jul 6 '12 at 3:37
  • Years later, and the bug is still present... May 29 '13 at 13:26

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

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

  • 3
    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. Nov 29 '10 at 11:42
  • 1
    @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) Nov 29 '10 at 22:14
  • 1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .