#12508 closed defect (fixed)
IE9: no keypress event for ENTER key
| Reported by: | bill | Owned by: | bill |
|---|---|---|---|
| Priority: | high | Milestone: | 1.5.2 |
| Component: | Events | Version: | 1.6.0 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: |
Description (last modified by )
IE6-8 fire a keypress event for the enter key, but IE9 doesn't, so we need to create a faux keypress event, just like we do for other unprintable keys.
Causes failures in dijit/tests/tree/robot/Tree_a11y.html and presumably many other tests.
Attachments (2)
Change History (14)
comment:1 Changed 9 years ago by
| Description: | modified (diff) |
|---|
comment:2 Changed 9 years ago by
Changed 9 years ago by
| Attachment: | ie9enterKeypress.patch added |
|---|
modify IE9 behavior to create faux keypress event for ENTER keydown event
comment:4 Changed 9 years ago by
Replying to bill:
Well, that code is inside of an
if(evt.ctrlKey){
D'oh, my bad.
So if I understand the patch correctly, it's essentially making keyCode 13 count as "unprintable" in the case of IE9 for the sake of simulating an event because IE9 no longer fires one itself?
Looks good to me, and I don't see any regressions in that test page in IE6-8.
comment:5 Changed 9 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:6 Changed 9 years ago by
comment:7 Changed 8 years ago by
| Milestone: | 1.6.1 → 1.5.2 |
|---|
comment:8 Changed 7 years ago by
Could someone explain in which context IE9 doesn't fire a keypress event for ENTER? The following page seems to work fine:
<!DOCTYPE html> <html> <head> </head> <body> <div tabindex="0" type="text" onkeypress="alert(event.key)">Click here and type ENTER</div> </body> </html>
I'm seeing cases where both the stealth keyPress and the real keyPress are happening.
comment:9 Changed 7 years ago by
Hmm, that's odd. Like I said above, the keypress event wasn't firing for the Tree_a11y.html test, presumably using the ENTER key to "click" a node of the Tree, but not sure why that case would be different from the one you gave.
comment:10 Changed 7 years ago by
Hmm, I retested the code before the patch was applied, and you can "keyboard click" a node in http://download.dojotoolkit.org/release-1.6.0/dojo-release-1.6.0/dijit/tests/tree/test_Tree.html and it works, printing "Execute of node Africa..." to the console. And even http://download.dojotoolkit.org/release-1.6.0/dojo-release-1.6.0/dijit/tests/tree/robot/Tree_a11y.html is working fine for me.
My best guess is that IE9 changed behavior in a patch release. I'll try the full regression.
comment:11 Changed 7 years ago by
Randy, can you file a new ticket (referencing this one) with the test case where you are getting multiple notifications for the enter key press?
comment:12 Changed 7 years ago by
PS: the IE9 regression still passes when rolling back [24086], but I just can't reproduce any problem with the currently checked in code. I'll attach my test where there's only one keypress event on enter.
Changed 7 years ago by
| Attachment: | connectKeypress.html added |
|---|
test case for possible double enter key notification
Perhaps I'm misreading, but it seems like we purposely kill enter keypress in IE regardless of version? See lines 439-440 of event.js (which is within a dojo.isIE block):
}else if(c==13||c==27){ c=0; // Mozilla considers ENTER and ESC non-printable