A couple of things to note here. ToT is not the same as Safari 2, so
keep that in mind.
event.keyCode is set to the Windows key code for keydown and keyup.
This means you should have consistency now across WebKit impls for
event.keyCode assuming everyone has implemented WindowsKeyCode
properly. For example on Mac if you alert for the down arrow key you
get 4040 in a keydown/keyup.
For keypress, event.keyCode is equivalent to event.charCode. The
char code is obtained by getting the first character of the key
event's "text" and returning that. This text is initialized in
platform/mac/KeyEventMac to be the raw characters of the event
according to the platform. In the case of down arrow for example,
this means you'll get 62323.
Note that the Web API WG has taken over DOM Level 3 Events in order
to better specify key events. You can find that spec here:
http://www.w3.org/TR/DOM-Level-3-Events/events.html
keyCode/charCode are basically being scrapped in favor of
keyIdentifier (implemented in ToT!), and - I believe - this system is
designed to yield consistent results across platforms.
dave
([EMAIL PROTECTED])
On Mar 28, 2007, at 3:43 PM, Adam Treat wrote:
Hi,
Currently the keycodes returned by the various platforms under
WebKit are
nowhere near close to uniform. This seems like something that
should be
standard across all platforms that WebKit provides. It is unclear
to me
exactly how the keycodes are generated by the different platforms...
In platform/qt/PlatformKeyboardEventQt.cpp the following snippet of
code seems
to handle the return code for the up arrow key:
case Qt::Key_Up:
return VK_UP; // (26) UP ARROW key
The equivalent code for the mac would seem to be in
platform/mac/KeyEventMac.mm:
// VK_UP (26) UP ARROW key
case NSUpArrowFunctionKey: return 0x26;
The actual behavior under Safari seems to be to return '63232'
I am not at all aware how this happens.
The current mess for javascript keycodes is nicely summarized on
this page.
http://www.unixpapa.com/js/key.html
If we can't fix this as a standard across browsers, surely this
could be fixed
across platforms that WebKit provides, no?
Adam
PS Any clue as to where Safari turns that code into '63232' would
be much
appreciated.
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
