Closed
Bug 445439
Opened 16 years ago
Closed 11 years ago
Assign W3C Level 3 spec attribute keyIdentifier to keyup/keydown event objects
Categories
(Core :: DOM: Events, enhancement)
Tracking
()
RESOLVED
INVALID
People
(Reporter: jacobsallan, Unassigned)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 The W3C DOM Event Level 3 specification adds an attribute 'keyIdentifier' to keydown and keyup events. The assignment of a String value to keyIdentifier is well-defined for control characters (like Esc or the arrow keys). Refer to the W3C web pages for the appropriate assignments. This bug report addresses the hard part of the problem: what to do with keys that are used for letters and digits. A mapping is defined for keyboard layouts on Windows XP. Definition of a similar set of mappings on Linux are blocked by other Firefox bugs and will have to wait. The keyIdentifier should be a function of both layout and keycode. The keyIdentifier should not simply be the keycode converted into hex. The W3C specification says that the assignment should reflect the Unicode values of the characters produced by the key. The algorithm used here: 1. Use a numeric value if it is available in normal, shift, or AltGr state. 2. If 1 does not apply and if the key has an upper/lower case assignment that is state dependent, use the Unicode for an upper case character. 3. If neither 1 nor 2 applies, use the Unicode for the normal state key assignment. 4. If 1, 2, and 3 do not apply, use the Unicode for the shift state key assignment. 5. If 1, 2, 3, and 4 do not apply, use the Unicode for the AltGr state key assignment. Shift state is obtained by depressing the Shift key and then the key in question. The less familiar AltGr state obtains when epressing the right Alt key and then the key in question. The Shift+AltGr state obtains when the Shift and right Alt keys are depressed when the key in question is keyed down. Normal state obtains when a key is depressed and neither the Shift nor the Alt keys are depressed. There is one more state that obtains for the Hebrew layout that is not relevant to this bug. The algorithm sketched above can be used to construct a new mapping for each of the Windows keyboard layouts. The table does not fit in a Bugzilla description field. The mapping starts out as follows: mysql> select distinct layout,keycode,upper(w3cIdentifier) from keymap where os='Win' and browser='FF' order by layout,keycode; +---------------------------------------+---------+----------------------+ | layout | keycode | upper(w3cidentifier) | +---------------------------------------+---------+----------------------+ | Albanian | 48 | U+0030 | | Albanian | 49 | U+0031 | | Albanian | 50 | U+0032 | | Albanian | 51 | U+0033 | | Albanian | 52 | U+0034 | | Albanian | 53 | U+0035 | | Albanian | 54 | U+0036 | | Albanian | 55 | U+0037 | | Albanian | 56 | U+0038 | | Albanian | 57 | U+0039 | | Albanian | 59 | U+00CB | | Albanian | 61 | U+003D | | Albanian | 65 | U+0041 | | Albanian | 66 | U+0042 | | Albanian | 67 | U+0043 | | Albanian | 68 | U+0044 | | Albanian | 69 | U+0045 | | Albanian | 70 | U+0046 | | Albanian | 71 | U+0047 | | Albanian | 72 | U+0048 | | Albanian | 73 | U+0049 | | Albanian | 74 | U+004A | | Albanian | 75 | U+004B | | Albanian | 76 | U+004C | | Albanian | 77 | U+004D | | Albanian | 78 | U+004E | | Albanian | 79 | U+004F | | Albanian | 80 | U+0050 | | Albanian | 81 | U+0051 | | Albanian | 82 | U+0052 | | Albanian | 83 | U+0053 | | Albanian | 84 | U+0054 | | Albanian | 85 | U+0055 | | Albanian | 86 | U+0056 | | Albanian | 87 | U+0057 | | Albanian | 88 | U+0058 | | Albanian | 89 | U+0059 | | Albanian | 90 | U+005A | | Albanian | 109 | U+002D | | Albanian | 188 | U+002C | | Albanian | 190 | U+002E | | Albanian | 191 | U+002F | | Albanian | 192 | U+005C | | Albanian | 219 | U+00C7 | | Albanian | 220 | U+005D | | Albanian | 221 | U+0040 | | Albanian | 222 | U+005B | | Albanian | 226 | U+003C | | Arabic (101) | 48 | U+0030 | | Arabic (101) | 49 | U+0031 | | Arabic (101) | 50 | U+0032 | | Arabic (101) | 51 | U+0033 | | Arabic (101) | 52 | U+0034 | | Arabic (101) | 53 | U+0035 | | Arabic (101) | 54 | U+0036 | | Arabic (101) | 55 | U+0037 | | Arabic (101) | 56 | U+0038 | | Arabic (101) | 57 | U+0039 | | Arabic (101) | 59 | U+0643 | | Arabic (101) | 61 | U+003D | | Arabic (101) | 65 | U+0634 | | Arabic (101) | 66 | U+0644 | | Arabic (101) | 67 | U+0624 | | Arabic (101) | 68 | U+064A | | Arabic (101) | 69 | U+062B | | Arabic (101) | 70 | U+0628 | | Arabic (101) | 71 | U+0644 | | Arabic (101) | 72 | U+0627 | | Arabic (101) | 73 | U+0647 | | Arabic (101) | 74 | U+062A | | Arabic (101) | 75 | U+0646 | | Arabic (101) | 76 | U+0645 | | Arabic (101) | 77 | U+0649 | | Arabic (101) | 78 | U+0627 | | Arabic (101) | 79 | U+062E | | Arabic (101) | 80 | U+062D | | Arabic (101) | 81 | U+0636 | | Arabic (101) | 82 | U+0642 | | Arabic (101) | 83 | U+0633 | | Arabic (101) | 84 | U+0641 | | Arabic (101) | 85 | U+0639 | | Arabic (101) | 86 | U+0631 | | Arabic (101) | 87 | U+0635 | | Arabic (101) | 88 | U+0621 | | Arabic (101) | 89 | U+063A | | Arabic (101) | 90 | U+0626 | | Arabic (101) | 109 | U+002D | | Arabic (101) | 188 | U+0629 | | Arabic (101) | 190 | U+0648 | | Arabic (101) | 191 | U+0632 | | Arabic (101) | 192 | U+0630 | | Arabic (101) | 219 | U+062C | | Arabic (101) | 220 | U+005C | | Arabic (101) | 221 | U+062F | | Arabic (101) | 222 | U+0637 | There is a similar bug submitted at webkit.org for Safari that assigns a consistent set of identifiers. The keyIdentifier attribute should prove to be more portable and usable than keyCode ever was. Reproducible: Always Steps to Reproduce: 1. Assign a listener for either keyup or keydown events and access the event. 2. Try the key to the left of the 'P' key. 3. Switch to a different layout (not Chinese, Japanese, or Korean which use IMEs) and repeat the experiment. The keycode will probably be the same (though not always), but the key will vary. 4. Switch to the US layout and type the 'A' key. 5. Switch to an Arabic layout and type the same key. The keycode will be a very different number. Expected Results: The expected results appear as an attachment.
Reporter | ||
Comment 1•16 years ago
|
||
Reporter | ||
Comment 2•16 years ago
|
||
The assignments assume that character assignment mistakes are corrected. The misassignments are documented in the SQL script FixBrowserBugs.sql. The maps provided make no assignments to keys that Firefox treats as active and that are not actually defined in a given layout. Internet Explorer is a little more careful about this and can be used as a check for the accuracy of the maps when they appear to be incomplete.
Reporter | ||
Comment 3•16 years ago
|
||
A separate bug will be filed for the Firefox character assignment bugs. Some or all of these may have already been reported.
Reporter | ||
Comment 4•16 years ago
|
||
There were a few misassignments of keycodes made that have consequences for keyIdentifier assignments. These were discovered by comparing the keyIdentifier assignments independently made for Firefox and Opera. With these corrections, it is my belief that the probability of an error is now roughly 1 in 10000 for Firefox and Internet Explorer. The error rate for Opera is larger. The database detected conflicts in keyCode assignments for Opera that cannot be patched. The assignment reading Belgian (Period) 226 U+003c should not have been made at all. The assignment reading Latvian 222 U+00b0 should read Latvian 222 U+00b4
Reporter | ||
Updated•14 years ago
|
Version: unspecified → 3.5 Branch
Updated•14 years ago
|
Attachment #329780 -
Attachment mime type: text/x-sql → text/plain
Comment 5•14 years ago
|
||
Cross-referencing the webkit bug with some discussion: https://bugs.webkit.org/show_bug.cgi?id=20027. Did you try to start a discussion in the mailing lists (w3c or mozilla's)?
Status: UNCONFIRMED → NEW
Component: General → DOM: Events
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → events
Version: 3.5 Branch → unspecified
Reporter | ||
Comment 6•14 years ago
|
||
I did not know how to go about starting such a discussion. I would appreciate an opportunity to work on this.
Comment 7•14 years ago
|
||
Note, DOM 3 Events doesn't have a property called .keyIndentifier. This bug is probably about .key and .char.
Comment 8•14 years ago
|
||
Allan, posting to the mozilla.dev.tech.dom newsgroup or the dev-tech-dom@lists.mozilla.org mailing list is one way to start the discussion.
Reporter | ||
Comment 9•14 years ago
|
||
(1) I'll post to either the mailing group or newsgroup as Boris Zbarsky advises. (2) About Olli Pettay's comment about keyIdentifier. That does seem to be true. The bug is 2 years old. The spec draft has changed. Rereading it, what I had in mind is the 'char' attribute for the DOM3 'textinput' event. http://www.w3.org/TR/DOM-Level-3-Events/#key-algorithm describes the algorithm for assignments of 'char'. There is a footnote that says the algorithm has changed. I'll poke around my computer and try to resurrect the code that processes the database data -- and attach that to this bug report. The SQL for the (MySQL database) is attached. (3) A bit of research at the Internet Explorer 9 preview pages is in order. The behavior described deviates from the W3C spec, is radically different from IE <9, and beautifully simple. http://msdn.microsoft.com/en-us/library/ms533023(VS.85).aspx#Keyboard_Events Quoted below: "Keyboard events occur when the user presses or releases a keyboard key. The onkeydown and onkeyup events fire when a key changes state as it pressed or released, respectively. These events fire for all keys on the keyboard, including shift state keys such as SHIFT, CTRL, and ALT. " "The onkeypress event fires when the user's keyboard input is translated to a character. These occur, for example, when the user presses letter or number keys, or a combination of shift keys and letters and numbers." "When a keyboard event occurs, the keyCode property of the event object contains the Unicode keycode of the corresponding key. The altKey, ctrlKey, and shiftKey properties specify the state of the ALT, CTRL, and SHIFT keys." "You can change which key is associated with the event by either changing the value of the keyCode property or returning an integer value. You can cancel the event by returning zero or false. " "The onhelp event is a special keyboard event that occurs when the user presses the help key (F1)."
Reporter | ||
Comment 10•14 years ago
|
||
The W3C specification has changed. Identifying the key independent of state (that is, of a modifier) is no longer one of it's ambitions. This makes this bug irrelevant. Bug 445439 should be closed. "keyidentifier" refers to content at http://www.w3.org/TR/2007/WD-DOM-Level-3-Events-20071221/events.html#Events-KeyboardEvent and at http://www.w3.org/TR/2007/WD-DOM-Level-3-Events-20071221/keyset.html . Refer to http://www.w3.org/TR/DOM-Level-3-Events/#keys-Guide , in a version of the W3C specification (dated Sept 7, 2010 -- two days ago). In the new draft, keyup, keydown, and keypress implement the KeyboardEvent interface which mandates the presence of attributes 'char', 'key', and 'keyCode'. Keycode is legacy. User codes will see a wild variation when changing browsers, operating systems, keyboard locales, and even shift states. For most visible characters, 'char' and 'key' will be assigned the same Unicode character value. The value depends on modifier state. 'char' and 'key' differ for some punctuation characters. For instance, hitting the spacebar causes an event with 'char' set to a space (\u0020) and 'key' set to the string 'Spacebar'. Characters with no character representation have 'char' set to null and 'key' assigned a meaningful value. For instance, an Up Arrow key has 'char'=null and 'key'='Up'. If I can remember my password, I'll update the webkit bug, too.
Reporter | ||
Comment 11•13 years ago
|
||
This bug might be useful for finishing 447757. Please do not close.
Comment 12•11 years ago
|
||
The property mentioned in the summary does not exist. Please file new bugs for other issues.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•