I typed a chat message including two pings. I believe I tab-completed @rumtscho and fully typed @MarthaF (since she doesn't tab complete). However, other people tell me that a Unicode character was inserted into the message; I can't see it:

Originally, I abandoned this bug report for a lack of reproducibility. But on another machine, I can see the character and managed to reproduce it: press tab, then press backspace. It works anywhere in a message, not just in a @-ping. (Actually, it seems that you just need to un-focus the input box; clicking elsewhere then hitting backspace works, too)

  • First machine is Firefox 12 (Iceweasel) on Debian GNU/Linux AMD64, testing+unstable. No user scripts. Greasemonkey is installed, but disabled in the extension manager
  • Second machine is Firefox 10 (Iceweasel) on Debian GNU/Linux AMD64, testing+unstable. No user scripts, Greasemonkey not even installed
  • Third machine (just tested) is Firefox 11 (Iceweasel) on Debian GNU/Linux AMD64. Greasemonkey installed and enabled, and there is a global userscript.
  • Does not happen on Chromium 18.0.1025.151, running on machine #3.

So far, that's all the machines I've tested on, and it happens on all of them. It only happens in chat.

Easiest way to produce it is to click on the page background, somewhere outside the text box, to un-focus the text box. Then press backspace. Note that not all browsers will display the character, even if its there (check this message to see if yours does)

  • 3
    Sounds to me that your Backspace is messing up, and pressing Tab has little to do with it. Does it actually remove the character you're trying to remove? For your browsers, does it also happen outside Chat, or in fields where there's no auto complete at all? Maybe even regular posts? (And it's odd you actually need to remove a tab character: in my browsers, I cannot "type" a tab as pressing Tab gets me to the next input field when there's no auto-completion match, but that might be different in Chat.)
    – Arjan
    Commented Jun 2, 2012 at 5:59
  • (As an aside, some online character-to-UTF8 encoder might help debugging.)
    – Arjan
    Commented Jun 2, 2012 at 9:16
  • Since U+0008 is the backspace character (U+0009 is tab), @Arjan is probably right. Do you use any user scripts? JavaScript writing String.fromCharCode(event.keyCode) to the input field or textarea would insert a backspace character instead of deleting the previous one.
    – Dennis
    Commented Jun 2, 2012 at 14:51
  • No, there aren't any user scripts; Greasemonkey isn't even installed. Tab was just to de-activate the textbox, apparently (tab itself isn't inserted). The first backspace just inserts ^H, it doesn't delete a character. Second backspace works as expected. It only happens on chat.SE.
    – derobert
    Commented Jun 2, 2012 at 15:12
  • 1
    Apparently still present: meta.stackexchange.com/q/296385
    – Jason C
    Commented May 24, 2017 at 19:01
  • Happens on IE, too.
    – Jason C
    Commented May 24, 2017 at 19:40

2 Answers 2


Steps reproduce this behavior with Firefox:

  1. Open the chat in a new tab.

    (There can't be any history in the tab, since pressing backspace would abandon the page.)

  2. Remove the focus from the <textarea>.

    (Pressing tab when there's nothing to autocomplete does this.)

  3. Press backspace.

I also think that I've isolated the faulty code in master-chat.js:

$(document).bind("keypress",function(a){if(!a.ctrlKey&&!a.altKey&&!a.metaKey){var b;if(a.which&&13!=a.which&&32!=a.which&&"input"!=(b=a.target.nodeName.toLowerCase())&&"textarea"!=b&&0==$(a.target).closest(".popup").length&&(b=String.fromCharCode(a.keyCode||a.which)))d.focus(),$.browser.mozilla&&d.val(d.val()+b)}}

The idea is to directly write to the <textarea> when a key is pressed, even if it doesn't have focus.

That works well in most cases, but not when pressing backspace:

  1. b=String.fromCharCode(a.keyCode||a.which) sets b="\x08".

  2. d.val(d.val()+b) writes U+0008 to the textarea.


  • This isn't a problem in Chrome, since pressing backspace doesn't trigger keypress in situations where Chrome attempts to go back in history.

  • Pressing backspace a second time behaves like expected, since the <textarea> has focus now.

  • "This isn't a problem in Chrome, since it attempts to go back in history when pressing backspace." Doesn't Firefox do that too? Commented Jun 2, 2012 at 16:46
  • @MichaelMrozek: I didn't express myself correctly. Firefox also uses backspace for going back in history, but it triggers keypress in addition.
    – Dennis
    Commented Jun 2, 2012 at 17:49
  • Nice, Sherlock. As an aside, but related: when I was using Firefox in OS X, I also used keyconfig to disable Delete for navigation (here, Delete being the Mac's name for Backspace), as sometimes using editors such as TinyMCE would make Delete go back while editing... Troublesome key :-)
    – Arjan
    Commented Jun 2, 2012 at 19:53
  • Backspace to go back in history? Must be some weird Windows thing. Firefox on Linux doesn't do that (instead, it's alt-left)
    – derobert
    Commented Jun 3, 2012 at 5:30
  • @derobert: Indeed. On Windows, backspace and alt-left work both. The strange thing is that backspace doesn't work in Chrome on Ubuntu (I never picked up on this, since I don't use backspace that way), but it still doesn't trigger keypress...
    – Dennis
    Commented Jun 3, 2012 at 5:40
  • I can reproduce this bug in Firefox 32.0.3 under Windows 8.1: chat.stackexchange.com/transcript/message/17966600#17966600 (not visible, but seems to be stored internally)
    – bwDraco
    Commented Oct 2, 2014 at 20:47

As Dennis has correctly noted, the culprit is the SE event handler that tries to capture keypresses anywhere on the page and redirect them to the input area. The problem is that the event handler is not smart enough to realize that (even after accounting for modifier keys, enter and space, which it already does) not all keypress events actually correspond to new characters that could or should just be appended to the input.

A better way to implement the event handler might be to have it re-trigger the keypress event on the input area instead, and rely on the browser's default event handling behavior to actually update the text. However, as a crude interim fix, I came up with the following code, which will install its own event handler to intercept any keypress events corresponding to control characters (character code < 32) and prevent them from reaching the SE event handler:

$('body#chat-body').on( 'keypress', function (e) {
    if ( e.ctrlKey || e.altKey || e.metaKey ) return;
    if ( !e.which || e.which >= 32 ) return;
} );

I have included this fix in version 1.4 of the Stack Overflow Unofficial Patch, a collection of client-side CSS and JavaScript fixes packaged as a GreaseMonkey-style user script. If you're using a compatible browser (Firefox, Chrome, Opera, possibly Safari and others, but unfortunately not IE or most mobile browsers), please give it a try!

You must log in to answer this question.

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