WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
Bug 19906
bad values for keyIdentifier for symbol keys on Windows
https://bugs.webkit.org/show_bug.cgi?id=19906
Summary
bad values for keyIdentifier for symbol keys on Windows
Jan Wolter
Reported
2008-07-05 18:56:30 PDT
Event.keyIdentifier gives incorrect values for a few keys under Windows. The values returned under OS X are correct. key Windows OS X `~ U+00C0 U+0060 -_ U+00BD U+002D =+ U+00BB U+003D [{ U+00DB U+005B ]} U+00DD U+005D \| U+00DC U+005C ;: U+00BA U+003B '" U+00DE U+0027 ,< U+00BC U+002C .> U+00BE U+002E /? U+00BF U+002F A couple other windows keys also give questionable keyIdentifier values. The NumLock key on the keypad gives "U+0090" when it should probably be "NumLock". The Windows Menu key (the thing between the left "Start" key and the "Ctrl" key on most windows keyboards, whatever it is called) gives "U+005D" which should be the value for the ]} key. I have no idea what that key should return. "Select" maybe? A slight deficiency (not quite a bug) is that the keyLocation values do not distinguish between left and right shift keys or control keys. Both shift keys return values of 0 instead of one returning 1 and the other 2. I believe this is true in both Windows and OS X versions. I don't even know if it is possible to make that distinction on all platforms. The URL above points to my key testing script. I've fairly thoroughly tested the key events in Safari and compared them to multitudes of other browsers, and have found no other deficiencies in Safari (leaving aside the textinput event). Very nice work.
Attachments
Add attachment
proposed patch, testcase, etc.
Jan Wolter
Comment 1
2008-07-09 08:59:17 PDT
After some additional research, I think the correct keyIdentifier value for the Windows Menu key would be "Apps". "Application Key" seems to be a common name for this thing.
Jan Wolter
Comment 2
2009-12-17 12:52:39 PST
In testing Chrome/4.0.249.43 for Linux (Webkit/532.5) I found that this bug occurs there too, in exactly the same way. Current versions of Safari for the Macintosh continue to return correct values.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug