Suppose I want to type the following comment:

The character for sun is 日, while the character for moon is 月.

To do this, I would type the following sequence of characters:

The character for sun is Alt+`hiSpaceEnterAlt+`, while the character for moon is Alt+`tukiSpaceEnterAlt+`.

But before I get to the end of my comment, the overzealous comment-submitting Enter key takes over the first time I press it, leaving me with a comment that looks like this:

The character for sun is 日

This problem has been brought up before:

  • Here on MSO, but only as an answer as near as I can tell.
  • On meta.Japanese.SE. The resolution of this problem for Japanese.SE (where basically everybody uses an IME (input method editor) that requires the Enter key to be pressed often as part of normal typing) was apparently to disable comment submission via the Enter key altogether, as near as I can tell.

This is a bug that should be fixed, whether by turning off Enter-submits-comments (which I guess the Powers That Be are opposed to) or by some other method.

(This might be a regression - I don't remember this happening to me before, but that might be because this is the first time I've tried using my IME in a comment outside of Japanese.SE. If it matters, I'm on Chrome 32.0.1700.76 on Windows 7, and I get this behavior using both Google Japanese Input and the Microsoft IME)

Update (21 Jan 2015): I cannot reproduce this behavior in Chrome 41.0.2272.12 dev-m on Windows 8. Maybe this was a bug in earlier versions of Chrome? In any case, if this issue is fixed in stable Chrome (I don't have it on any of my machines because of this), this should probably be marked .

  • The character for sun is 日
    – senshin
    Jan 20, 2014 at 18:39
  • 1
    @ShadowWizard That is a feature request; this is a bug.
    – senshin
    Jan 20, 2014 at 18:43
  • 5
    Not a bug, there's already a three years old request to change the current behaviour. Bug is when something isn't working as planned, in this case ENTER submitting the comment was planned. Jan 20, 2014 at 18:43
  • 6
    @ShadowWizard The current behavior is demonstrably incorrect with regard to IMEs. This is not a matter of personal preference (in terms of how one thinks comments should work), unless you believe people on Stack Exchange should not use IMEs.
    – senshin
    Jan 20, 2014 at 18:44
  • 1
    Let's agree to disagree then, this would be marked status-bydesign sooner or later. Jan 20, 2014 at 18:57
  • Original close vote retracted, here's a better duplicate: Cannot get to a new line by hitting Enter Jan 20, 2014 at 18:59
  • @senshin: Does Shift-ENTER work? Jan 20, 2014 at 19:27
  • @MartijnPieters Well, let's find out. 日 (Apparently Shift+Enter doesn't submit, but it also doesn't leave the IME's selection mode, so that's a no-go.)
    – senshin
    Jan 20, 2014 at 19:28
  • @senshin: Does that mean Shift-ENTER doesn't work for you and posts the comment immediately? Jan 20, 2014 at 19:41
  • 2
    @MartijnPieters I mean that Shift+Enter does nothing at all when I'm still entering text in the IME. It neither posts the comment nor gets me out of IME text-entering mode. Of course, once I'm out of the IME, I can press Shift+Enter to get a newline in the comment box, but that's not relevant.
    – senshin
    Jan 20, 2014 at 19:44
  • @senshin: It was worth a shot; it would have been a work-around if it had worked. A pity! Jan 20, 2014 at 19:54
  • The work-around I use on a Mac (I don't remember if it applies to Win 7) would be to select the appropriate character in the IME and then toggle out of the IME (back to English) back in to continue typing. Switching out of the IME would lock in that character selection.
    – Troyen
    Jan 21, 2014 at 0:40
  • 2
    @senshin: Would you mind testing this development version of my SOUP user script (using GreaseMonkey for Firefox or TamperMonkey for Chrome) and see if it fixes this? I think it might, since it does fix a similar issue, but I've never really used an IME so I'm not sure. Jan 21, 2014 at 23:32
  • 3
    While the proposed duplicate does ask for Enter to not submit the comment, this current question presents a real problem that requires that while the other is just a request for formatting. So for that reason I don't think this is a duplicate. Oct 3, 2014 at 1:13
  • 1
    Looks like this was fixed a couple of months ago. Oct 5, 2016 at 17:37

3 Answers 3


I've encountered such issues before (in other web apps). This issue happens on all sites when the user uses the keyboard to select a spell check suggestion (arrows + Enter).

The solution to this problem is to not use the keyup event, but the keydown event.
When I check the source code of http://dev.meta.stackoverflow.com/content/Js/full.en.js, I can see that the submit-on-Enter feature is implemented using:

var bind_submitOnEnterPress = function(jForm)
            if (event.which == 13 && !event.shiftKey && !$(this).prev("#tabcomplete:visible").length)
            if (event.which == 13 && !event.shiftKey)
                return false

Replacing keyup with keydown (and removing keypress) ought to solve the problem.


As I mentioned in the comments above, I've come up with what I hope is a client-side JavaScript fix for both this bug as well as this non-IME-related one:

StackExchange.options.desc = true;

$('body').on( 'keydown keypress', 'form[id*="-comment-"] textarea',
    function (e) {
        if ( e.which != 13 || e.shiftKey ) return;
        if ( e.type == 'keydown' &&
            $(this).prev('#tabcomplete:visible').length == 0 )

This code does pretty much exactly what Rob W suggests in his answer:

  • The first line simply sets a config option that tells the Stack Exchange JS code not to attach its normal submit-on-enter event handler. This option is currently enabled by default e.g. on Japanese Language Stack Exchange, where this bug has apparently caused enough problems to convince the developers to disable comment submission using the enter key.

  • The rest of the code sets up a custom keyboard event handler that does pretty much the same thing as the SE event handler we just disabled, except that it's attached to the keydown event rather than to keyup. It appears that this simple change is enough to fix the bug.

    (I'm also using the same handler to suppress the default behavior of the keypress event, which would insert a line break in the text; the SE code uses a separate event handler for that.)

I have included this fix in version 1.4 of the Stack Overflow Unofficial Patch, a collection of client-side user interface fixes for Stack Exchange sites. If you're using an IME and a browser with user script support, such as Firefox (with GreaseMonkey), Chrome (with Tampermonkey), Opera (native support) or possibly Safari (with NinjaKit), please give it a try!

Note: If you try SOUP and find that it does not fix this bug for you, or that it has any undesirable side effects, please let me know! Apparently, this bug is only triggered by some combinations of browser, OS, IME and possibly keyboard / locale, and I can't rule out the possibility that this fix might not work for all of them. (In fact, since I don't normally use an IME myself, my ability to test this fix has been quite limited. I'm fairly confident that it at least shouldn't make things any worse, but that's about it.)


If they want to keep it by design, probably it still should be an user preference, so everyone that's happy with current behaviour will stay happy, and the ones that use IME can disable the enter to submit without affecting others.


You must log in to answer this question.

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