What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 131 Stack Exchange communities.

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 )

share|improve this question
    
This doesn't happen in Chrome 6. It does occur in IE7 and FF 3.6 –  Barry Oct 5 '10 at 7:32
    
Oh, you're just tempting Jeff, Tobias. –  Michael Petrotta 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? –  Tobias Kienzler Oct 5 '10 at 7:50
    
@Tobias - Can't you use the keyboard shortcuts? –  Barry Oct 5 '10 at 7:57
2  
@Barry: which ones? For ClipX yes, but for spelling correction, the correction suggestions don't have any –  Tobias Kienzler 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. –  Marcel Korpel 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

3 Answers 3

up vote 2 down vote accepted

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 version 1.4 of the Stack Overflow Unofficial Patch using the following code:

StackExchange.options.desc = true;

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

The first line of the above code simply sets a configuration option that tells the Stack Exchange UI code not to attach its own enter key handlers to comment forms; this option is enabled by default on sites like Japanese Language Stack Exchange, where the IME bug (which this patch also, apparently, fixes) has caused enough problems to convince the developers to turn it off.

The rest of the code sets up a delegated event handler that replaces the SE one. It's based on the SE event handler (found here in the bind_submitOnEnterPress function), and does pretty much the exact same thing, except that it's triggered on the keydown rather than on the keyup event. (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.)

In particular, the extra #tabcomplete:visible check has been copied verbatim from the original SE event handler. Actually, I suspect that it may not be needed at all, since it was presumably added to the original code to sidestep yet another variant of this very same issue, but I've left it in just for the sake of caution.

share|improve this answer
    
Awesome analysis! Also, I didn't know about SOUP, definitely worth checking out –  Tobias Kienzler Jan 26 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.

share|improve this answer
    
+1 Your script works partly - unfortunately it also blocks posting via Enter –  Tobias Kienzler 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 :) –  Tobias Kienzler 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... –  Tobias Kienzler 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.

share|improve this answer
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. –  Marcel Korpel 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) –  Jeff Atwood Nov 29 '10 at 22:14
    

You must log in to answer this question.

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