ctrl-punctuation normalization broken

[bill]

See enterKeyHandling.html for test case.

CTRL-equals on FF3.5 will produce evt(charOrCode="=", ctrlKey=true), as expected, but on IE6 it will produce an unexpected evt(charOrCode="+", ctrlKey=true),

CTRL-minus on FF3.5 will produce an unexpected evt(charOrCode=",").

Safari 4 is stranger, it produces two onkeypress events. For CTRL-equals it will produce an event with charOrCode="+" and another with charOrCode="=".

I'm not sure we need to support ctrl-punctuation, but there is code in events.js to support it:

// For IE and Safari: some ctrl-key combinations (mostly w/punctuation) do not emit a char code in IE
// we map those virtual key codes to ascii here
// not valid for all (non-US) keyboards, so maybe we shouldn't bother
_punctMap: { 
	106:42, 
	111:47, 
	186:59, 
	187:43, 
	188:44, 
	189:45, 
	190:46, 
	191:47, 
	192:96, 
	219:91, 
	220:92, 
	221:93, 
	222:39 
}

So, we should either get rid of the bugs, or get rid of the code.

[bill]

(In [18744]) Automated test for keyboard event handling, showing safari 4 problems with ESC and ctrl-q. Refs #9511, #9527, #9528.

Maybe this should be added to runTests.html although we don't have any robot tests in there currently.

[bill]

(sadly) punting seemingly abandoned ticket and meta tickets to future

[bill]

Kris, what do you want to do with this one?

I know you hate the keypress/keydown normalization from the old dojo.connect() code.

OTOH, even with the new dojo/on module, CTRL-= gives inconsistent results for IE6 (keyDown event with keyCode=187) vs. for FF (keydown event with keyCode=61). (I'm ignoring the keypress event that occurs on firefox.) So, not sure how a dojo application is supposed to test for CTRL-=?

[dylan]

Ticket planning... move current 1.13 tickets out to 1.15 to make it easier to move tickets into the 1.13 milestone.