#6667 closed defect (fixed)
IE key events don't match Firefox
Reported by: | Douglas Hays | Owned by: | Douglas Hays |
---|---|---|---|
Priority: | high | Milestone: | 1.2 |
Component: | General | Version: | 1.1.0 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
Pressng the left paren key "(" generates
keyCode=40, charCode=40 on IE6, but
on FF2 and Safari, it generates, keyCode=0, charCode=40.
Since Firefox is the standard, IE is broken.
This is causing dijit/tests/form/test_ComboBox.html to fail.
Run the test in IE6, focus the first box with Iowa and try to type (.
The dropdown appears since the code thinks the down arrow was typed since it also has keyCode=40.
This works fine in FF and Safari.
Change History (15)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
It's not possible to patch all the codes under IE.
IIRC, the rule for Dojo key events is that you have to check charCode first to determine if it's a printable character; only if the charCode is 0 is it considered safe to check keyCode.
If my recollection is faulty, please heap abuse as needed. :)
comment:3 Changed 13 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:4 Changed 13 years ago by
I don't remember the rule myself, I thought there was something about using keydown vs. keypress events for printable vs. non-printable characters, can you refresh my memory on that? (see also #5869)
comment:5 Changed 13 years ago by
I'm assuming this is what this snippet is for:
var dk = dojo.keys; var key = (e.charCode == dk.SPACE ? dk.SPACE : e.keyCode);
comment:6 Changed 13 years ago by
Resolution: | invalid |
---|---|
Status: | closed → reopened |
comment:7 Changed 13 years ago by
Owner: | changed from sjmiles to Douglas Hays |
---|---|
Status: | reopened → new |
I'll have to add workarounds in dijit.
comment:8 Changed 13 years ago by
The current key event implementation seems wasteful and will cause code bloat:
if(evt.keyCode == dojo.keys.DOWN_ARROW)
becomes
if(evt.charCode == 0 && evt.keyCode == dojo.keys.DOWN_ARROW)
In my opinion, the IE keypress event should be normalized to match Firefox.
The only dojo core change would be to zero out the keyCode if charCode != 0.
I'll use this defect to add the extra code throughout dijit.
comment:9 Changed 13 years ago by
Unfortunately we cannot "normalize IE event to Firefox", this was already tried. From line 322 in event.js:
// Mozilla sets keyCode to 0 when there is a charCode // but that stops the event on IE.
I should have been clearer that it's not some arbitrary decision I was making. :)
Alternatives I have considered are:
- Synthesize a phony event object for keypress. This could work, but there also could be consequences.
- Come up with a whole new model for handling keyboard. This is an area where browser compatibility is even more broken that usual due to an utterly vague spec. This could be some kind of YUI-like connect-to-this-key, or some kind of overlaid implementation of the latest w3c draft.
Neither of these is something that can be done haphazardly.
Sorry for confusion on valid/invalid. IMO, this is previously trodden ground, and the defect is not with the event system, but how Dijit has implemented key handling. I realize it's not at all cut-n-dry, so if you want to attach fixes to this ticket, I won't squawk.
Currently keyboard code should look something like this:
if (evt.charCode) { // handle printable keys (using charCode and keyChar) } else { // handle non-printable keys (using keyCode) }
comment:10 Changed 13 years ago by
Thanks for the explanation.
evt.keyChar is almost perfect, except it sets the invalid value to an empty string instead of evt.keyCode.
If it were changed, then we could do:
switch(evt.keyChar){ case dojo.keys.DOWN_ARROW: blah; case dojo.keys.UP_ARROW: blah; case 'w': blah; case dojo.keys.ENTER: case ' ': buttonpressed();
I wanted to point out that often a switch statement is used for key handling and that both kinds of keys (named numeric and literal ascii chars) are used, and that often they need to be logically together (ie. ENTER and space for button presses).
I've been changing the code throughout digit to be:
switch(evt.keyChar || evt.keyCode)
I doubt we can change keyChar at its creation time to incorporate evt.keyCode for backward-compatibility reasons.
comment:11 follow-up: 12 Changed 13 years ago by
change keyChar at its creation time to incorporate evt.keyCode
That's a really good idea.
As you say, if anybody is relying on evt.keyChar being "", then we would break them. But offhand it seems like a worthy risk.
keyCode). |
comment:13 Changed 13 years ago by
comment:14 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
IBM #84322