KeyUp, KeyDown, KeyPress vs Elements and Browsers

It is becoming fairly apparent that I am going to need to reconsider the approach that I take with ctrl_alt_foo, the Dart package that I am building out to handle keyboard shortcuts. Browsers certainly are a pain in this respect, populating different properties, firing different events in different order (or sometime not at all). I always knew this was a pain, but never fully appreciated the efforts that go into things like jQuery.

Before making wholesale changes, I am going to explore one more area of browser testing: Apple support. Ew.

Before I switch to OSX, I create a web page with simple JavaScript listeners both on an INPUT field and the BODY. In Chrome, I make the INPUT field active and type b. I then find that both the INPUT and BODY see the same events:



Interestingly, the keyIdentifier is blank for keyPress events. Good to know since ctrl_alt_foo relies on this property when generating keyboard events. It seems that I will not be able to reliable test keyPress events in Dart just yet.

There are no surprises when I type Shift + b (aka “B”):



Unlike the lowercase “b” the keycodes are all the same. Key up/down see the uppercase key in keyCode regardless of any modifier keys (including the Shift key). In this case, the key press event is also a capital “B” by virtue of my holding the Shift key while typing b.

Next up, I click outside of the INPUT so that the events will go directly to the BODY. I find that the BODY tag sees the event no differently than when the target is the INPUT field:



There is no difference with Shift+b in the BODY either:



Next, I try Ctrl+b with focus back in the INPUT field:



Interestingly, there is no key press event in this case. I suppose that this is because there is no character representation. Internet Explorer does the same thing, but Firefox opts to be different here and actually does see a key press event.

Finally, I try Ctrl+b with the BODY active and find:



Weird! There is a keypress event in this case, but the keyCode is a nonsensical 2!

Rather than shift off to OSX tonight, I take a little time to explore Firefox and Internet Explorer. For these, I add charCode as keyCode is not always populated. For instance, the keypress event in Firefox:



Internet Explorer is actually nice about this. It always populates keyCode, but tries to follow Firefox's example in key presses by also populating charCode:



Since I have this up, I give my Enter in INPUT a whirl with Internet Explorer:



Wild! The BODY sees the key up event, but the target is no longer the INPUT field. Somehow it shifts to the BUTTON (the INPUT and BUTTON are not part of the same FORM).

In all other browsers, the key up event is seen by the INPUT field:



I try moving the BUTTON around the document, but Internet Explorer always sends key events to it. If I remove the BUTTON, then Internet Explorer sends the key up event to the INPUT field. That has to be a bug, right?

Wanna give it a try? I have a version of the event tester available at http://japhr.blogspot.com/p/keyboard-event-tester.html.

This seems an opportune time to call it a night. Tomorrow I will boot into OSX and give it a whirl (and test my Meta-key hypothesis).

I have no idea how the Dart developers are going to normalize all of this behavior. As crazy as it seems, it does help me in my thinking about what ctrl_alt_foo needs to work.

Day #844

‹prev | My Chain | next›