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

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)

share|improve this question
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 Jun 2 '12 at 5:59
    
(As an aside, some online character-to-UTF8 encoder might help debugging.) –  Arjan Jun 2 '12 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 Jun 2 '12 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 Jun 2 '12 at 15:12

2 Answers 2

up vote 10 down vote accepted

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.

Note:

  • 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.

share|improve this answer
    
"This isn't a problem in Chrome, since it attempts to go back in history when pressing backspace." Doesn't Firefox do that too? –  Michael Mrozek Jun 2 '12 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 Jun 2 '12 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 Jun 2 '12 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 Jun 3 '12 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 Jun 3 '12 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) –  DragonLord the Fiery Oct 2 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;
    e.stopPropagation();
} );

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!

share|improve this answer

You must log in to answer this question.

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