Forums

Ah, nearly forgot. One thing to note with the jsfiddle example, is that it implements the YUI 'feature' / 'bug', by overriding the 'which' state. This is fine if you can refer to the Native 'charCode' value. But what this doesn't allow is the passing of the 'ENTER' key. The enter key is considered by FF to be special in that 'charCode' is set to zero. However, it is also considered a legitimate character in that the 'which' property is set to 13. Since IE and Chrome receive the ENTER key in their keypress events, this is somewhat consistent. But relying on the YUI wrapped value of 'which' makes it impossible to identify, given that 'charCode' in the jsfiddle example is zero for enter and 'which' is 13, but the same said for 'Page Up' where 'which' is 36 and 'charCode' remains at zero.

You should definitely file an issue and include all this information there.

Broad brushed indeed. It's the fix I have opted for in the interim, loading a bolt on module through metadata triggers. Seems to work for the browsers we support at least: Chrome, IE (7,8,9,10), FF (All versions).

I did read a really interesting article on the subject, which did include more browsers in it's research, such as Safari. It is one that shed light on how Mozilla overload the use of 'which', which is really intended for mouse clicks (which button).

http://unixpapa.com/js/key.html

Mozilla documentation about the which property is vague. It suggests that it is set to either the keyCode or charCode, depending whether a unicode character can be formed from the key combination. It doesn't indicated it will ever be zero. The doc on charCode however, says that charCode will be zero if keyCode is set and vice-versa, based on the same principle that a unicode character can be formed. It also suggests there is some complicated locale specific code that determines the charCode, so I'd say it's not simple to implement a synthetic keypress from a keydown.

https://developer.mozilla.org/en-US/docs/DOM/event.which

Also, I had thought about the Shift Key flag idea, but it doesn't really tell you anything about what happened. If you press Shift + PageUp the keyCode is still 33 as is '!', and obviously the shift key is depressed when constructing a '!'. You would still need to know whether a unicode character was pressed or not.

What I have understood from this experience and what I have read on the topic, is that most people would expect the browser not to issue a keypress event for a non-printing key, since keypress events are typically used to record textual key strokes. IE and Chrome can both agree on this, since you only receive the Enter key, given that it is a printing character when you think of it as '\n'. For example, if you want to validate data entry on a key stroke, you just need to know the character that would appear if your event handler doesn't prevent default. If there is no character, why would you want to know that a key was even pressed? If you wanted to listen to buttons and key combinations, you would most definitely use a keydown event, since that captures all keys pressed and never issues an event containing character codes.

I had thought about the synthesising the keypress for special chars in IE and Chrome, but really thought that there is no point. Natively, these two browsers don't do it, so without YUI you would be hard strapped to receive events for special chars in a keypress.

I have looked at ExtJS and how they deal with the issue, just as another point-of-view. It seems they don't fix the issue or synthesize a keypress event, but what they have done is created a new property on their event that encapsulates meaning across all browsers: isSpecialKey. They have normalized the other fields too, but only after creating this property, based on similar rules, though I fear they may have overlooked the backspace key, for which charCode is zero but which is set. But at least you get some idea in all browser variants, as to whether a special key was pressed or charCode is actually what it says it is, so your event handler can be simplified to:

if (e.isSpecialKey) { return true; }

I think I only provide part of the story given our small browser catalogue, so I do think a more robust solution needs to be developed, but that I will leave up to the YUI team to sort out. I will raise a ticket...

Thanks!