Keys list as below: - Directional Keys (mapping to Arrow keys) - OK key (to activate current selection or accept current input) - Soft Menu keys (two keys: left and right, can be flexibly programmable as application’s context) - HOME (used to go to home application) - CALL (depends on current viewing content, performs outgoing call initiation or displaying Call History) - END (CALL_END, if there's a call in progress, end it; short-press behaves ‘Home’, long-press behaves ‘Power’) - Back key (go back to the previous state or page in an Application, or leave the application if there is no previous state or page) - Clear key (editing keys, clear all typing text) - App launch keys (application shortcuts) - Camera key - Volume Keys (Multimedia keys, volume up and down) - 12-keys (numbers, ‘*’ and ‘#’)

After reading reference [1][2][3], my proposal is: Directional Keys (mapping to Arrow keys) - code: ArrowDown / ArrowLeft / ArrowRight / ArrowUp - key: ArrowDown / ArrowLeft / ArrowRight / ArrowUp - VirtualKeyCode: DOM_VK_DOWN / DOM_VK_LEFT / DOM_VK_RIGHT / DOM_VK_UP OK key (to activate current selection or accept current input) - code: Enter - key: Enter - VirtualKeyCode: DOM_VK_RETURN or DOM_VK_SELECT? Soft Menu keys (two keys: left and right, can be flexibly programmable as application’s context) - code: undefined - key: Soft1 / Soft2 - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 HOME (used to go to home application) - code: undefined - key: LaunchHome - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 CALL (depends on current viewing content, performs outgoing call initiation or displaying Call History) - code: undefined - key: Call (proposal) - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 END (CALL_END, if there's a call in progress, end it; short-press behaves ‘Home’, long-press behaves ‘Power’) - code: undefined - key: Exit (defined in Media Controller Keys) - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 Back key (go back to the previous state or page in an Application, or leave the application if there is no previous state or page) - code: Escape or BrowserBack - key: Escape or BrowserBack - VirtualKeyCode: DOM_VK_ESCAPE or ? Clear key (editing keys, clear all typing text) - code: undefined - key: Clear - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 App launch keys (application shortcuts) - code: LaunchApp1 / LaunchApp2 / … - key: Launch* (* represents a built-in application name) - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 Camera key - code: undefined - key: Camera / - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 Volume Keys (Multimedia keys) - code: VolumeDown / VolumeUp - key: VolumeDown / VolumeUp - VirtualKeyCode: DOM_VK_VOLUME_DOWN / DOM_VK_VOLUME_UP 12-keys (numbers, ‘*’ and ‘#’) * numbers (0-9) - code: Numpad0 / Numpad1 / … - key: 0 / 1 / … - VirtualKeyCode: DOM_VK_NUMPAD0 / DOM_VK_NUMPAD0 / … * pound key (‘#’) - code: IntlHash - key: # - VirtualKeyCode: DOM_VK_HASH * star key (‘*’) - code: NumpadMultiply - key: * - VirtualKeyCode: DOM_VK_MULTIPLY

[1] DOM Level 3 KeyboardEvent key Values http://www.w3.org/TR/2014/WD-DOM-Level-3-Events-key-20140612/#keys-editing [2] DOM Level 3 KeyboardEvent code Values http://www.w3.org/TR/DOM-Level-3-Events-code/#code-value-tables [3] Mozilla DOM Lv 2 KeyEvent webidl http://dxr.mozilla.org/mozilla-central/source/dom/webidl/KeyEvent.webidl

Hi Masayuki, I'm not sure if my proposal in comment 1 is the best match, could you review it and provide some feedback? Please also refer to attachment 8537994 [details] for vendor's proposal. I also got the following two questions when reading spec: 1) I'm not sure if we start implementing DOM Lv3 events, should we follow key and code definition for these new keyboard events? 2) Could we extend key and code definition when there is no definition in the spec? like the Call and Call_End in our case. Thank you.

(In reply to Evelyn Hung [:evelyn] from comment #3) > Hi Masayuki, > > I'm not sure if my proposal in comment 1 is the best match, could you review > it and provide some feedback? Please also refer to attachment 8537994 [details] > [details] for vendor's proposal. Sorry, should be attachment 8538011 [details].

First, KeyboardEvent.code is still unstable, we have not enabled it on release builds yet due to spec-bug 24739 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=24739). The motivation of .code is that web application can identify physical keys. However, currently, the spec defines keys only of PC keyboards. Strictly speaking, it's safe to set empty string values to all .code value for such phone device. However, some scancode (I assume HW in the table means scancode) values which are mapped to .code values in the table are same as PC keyboards. So, I think that it's okay to use current mapping. Note that our mapping table is defined here: http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h Next, I'll check about .key, please wait.

Oops, the table doesn't have all keys... I'd like to see all scancode values of other keys for judging .code mapping.

(In reply to Evelyn Hung [:evelyn] from comment #1) > Directional Keys (mapping to Arrow keys) > - key: ArrowDown / ArrowLeft / ArrowRight / ArrowUp This is okay, but we still use legacy key values, see bug 900390. Now, we still wait some response from WD for changing .key values in one release. So, please map the legacy key values for now. However, its applications should check both legacy .key value and new .key value with || operator. > - VirtualKeyCode: DOM_VK_DOWN / DOM_VK_LEFT / DOM_VK_RIGHT / DOM_VK_UP This is okay. > OK key (to activate current selection or accept current input) > - key: Enter > - VirtualKeyCode: DOM_VK_RETURN or DOM_VK_SELECT? Using "Enter" is good choice because I guess that most web applications must not check "Accept". Its keyCode should be DOM_VK_RETURN. > Soft Menu keys (two keys: left and right, can be flexibly programmable as > application’s context) > - key: Soft1 / Soft2 This is difficult. I guess that using these values doesn't cause any compatibility problem with web applications at least for now. However, web applications cannot *guess* the keys what users expected. Therefore, it might be better to map key values which represent typical purpose of the keys. I'm not sure the actual usage of the keys, though. > - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 Should be back here after .key value for them fixed. If the values are Soft1 and Soft2, we should use 0. Otherwise, use proper values for the decided keys. > HOME (used to go to home application) > - key: LaunchHome This may be a good choice. However, we're not sure other implementations what maps to this. If this key isn't exposed to applications and web contents, it might be better to append "Moz" prefix for the key name. > - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 This must be the best. > CALL (depends on current viewing content, performs outgoing call initiation > or displaying Call History) > - key: Call (proposal) Mobile phone key names won't be defined in D3E, it would be defined in UI Events (a.k.a. D4E). https://www.w3.org/Bugs/Public/show_bug.cgi?id=21121 Therefore, if we need to define this key name, my favorite is PhoneCall for clearing for what. And it should be MozPhoneCall for better compatibility with future's spec. > - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 Currently, we use it, so, must be this is the best. http://mxr.mozilla.org/mozilla-central/source/widget/gonk/GonkKeyMapping.h#32 > END (CALL_END, if there's a call in progress, end it; short-press behaves > ‘Home’, long-press behaves ‘Power’) > - key: Exit (defined in Media Controller Keys) I guess that Power is better because the Android keycode is KEYCODE_POWER. > - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 If the .key value is Power, it should be DOM_VK_SLEEP for now. http://mxr.mozilla.org/mozilla-central/source/widget/gonk/GonkKeyMapping.h#53 > Back key (go back to the previous state or page in an Application, or leave > the application if there is no previous state or page) > - key: Escape or BrowserBack Sounds like BrowserBack is better. > - VirtualKeyCode: DOM_VK_ESCAPE or ? Should be 0 if you decide to use BrowserBack. https://bugzilla.mozilla.org/attachment.cgi?id=8446451&action=diff > Clear key (editing keys, clear all typing text) > - code: undefined > - key: Clear Does "clear all typying text" mean canceling the composition of IME? or Removing whole text including already committed text in <input> or something? If it's the former, Escape is better, but I'd like to know the scancode and Android keycode. Note that Clear key is very minor key on other platforms. So, web application must not be handling it. However, if it doesn't work as like Esc key on PC, we shouldn't use Escape to this key, though. > - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 If it's Escape, DOM_VK_ESCAPE. > App launch keys (application shortcuts) > - key: Launch* (* represents a built-in application name) I think that this is okay. > - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 ditto. > Camera key > - key: Camera / I think this is okay too. > - VirtualKeyCode: DOM_VK_UNDEFINED, 0x00 ditto. > Volume Keys (Multimedia keys) > - key: VolumeDown / VolumeUp Okay. > - VirtualKeyCode: DOM_VK_VOLUME_DOWN / DOM_VK_VOLUME_UP ditto. > 12-keys (numbers, ‘*’ and ‘#’) > * numbers (0-9) > - key: 0 / 1 / … Using actual inputting characters is correct. > - VirtualKeyCode: DOM_VK_NUMPAD0 / DOM_VK_NUMPAD0 / … This is what we need to be careful. I guess that this is okay. But I worry about NumLock state (.getModifierState("NumLock")) and .location value. Please be careful if you assume they are in Numpad. > * pound key (‘#’) > - key: # No problem. > - VirtualKeyCode: DOM_VK_HASH If you assume that this is also in Numpad, 0 might be better because there is no such key. However, I guess that using DOM_VK_HASH shouldn't cause any problem. So, let's use DOM_VK_HASH. However, you should be careful about NumLock state and location. > * star key (‘*’) > - key: * > - VirtualKeyCode: DOM_VK_MULTIPLY DOM_VK_MULTIPLY must be in Numpad. If it's not in Numpad logically, DOM_VK_ASTERISK is better. Note that our .key mapping table is here: http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMKeyName.h

(In reply to Evelyn Hung [:evelyn] from comment #3) > 1) I'm not sure if we start implementing DOM Lv3 events, should we follow > key and code definition for these new keyboard events? Now, we have a lot of pending patches for conforming with the latest spec. However, we still wait some spec bugs will be fixed. But we have no response from WD of D3E for several months... At least for now, we should use only already defined key values even if they are legacy name. See also bug 900372. > 2) Could we extend key and code definition when there is no definition in > the spec? like the Call and Call_End in our case. Basically, no. If we need new key values except Launch*, F* and Soft*. However, if some of them necessary for the real product, *I* think that we should define non-standard key names with "Moz" prefix.

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #7) > Oops, the table doesn't have all keys... I'd like to see all scancode values > of other keys for judging .code mapping. I'm not sure if HW means scancode... LG people, could you confirm that? and if they are scancode, could you also provide all scancode values for the whole key set as I listed in this bug? Thanks!

Thank you so much for the detailed explanation! Comment unclear part inline. (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #8) > (In reply to Evelyn Hung [:evelyn] from comment #1) > > > Soft Menu keys (two keys: left and right, can be flexibly programmable as > > application’s context) > > - key: Soft1 / Soft2 > > This is difficult. I guess that using these values doesn't cause any > compatibility problem with web applications at least for now. However, web > applications cannot *guess* the keys what users expected. Therefore, it > might be better to map key values which represent typical purpose of the > keys. I'm not sure the actual usage of the keys, though. > The foreground web application defines what it means, and shows labels on the screen. (Please see my attached image and hope my edit on the image expresses more.) The two keys provide flexibility to applications to use them as a shortcut for some purposes. Usually he actual usages are: showing more 'options', entering 'edit' mode or 'exit'... However, we can't assume it's real usage, it's up to the foreground app. I feel it's new to this spec, so maybe Soft1 or Soft2 aren't the best match, and the description on the spec 'General purpose virtual function key' is unclear to me. > > CALL (depends on current viewing content, performs outgoing call initiation > > or displaying Call History) > > - key: Call (proposal) > > Mobile phone key names won't be defined in D3E, it would be defined in UI > Events (a.k.a. D4E). > https://www.w3.org/Bugs/Public/show_bug.cgi?id=21121 > Therefore, if we need to define this key name, my favorite is PhoneCall for > clearing for what. And it should be MozPhoneCall for better compatibility > with future's spec. > MozPhoneCall sounds good to me. Thanks! > > END (CALL_END, if there's a call in progress, end it; short-press behaves > > ‘Home’, long-press behaves ‘Power’) > > - key: Exit (defined in Media Controller Keys) > > I guess that Power is better because the Android keycode is KEYCODE_POWER. > It's a bit weird to listen to Power for hanging up a call... The key was overloaded for various usages in that old time. To be honest, 'power' is the least attractive function on the keypad, it even doesn't have a label! (/me couldn't find a button to power-on the phone when I got one.) Since we use 'MozPhoneCall' above, why don't we also follow the D4E spec and give it 'MozPhoneHangup'? On the other hand, power on/off function is controlled by System app so I feel okay to make less sense here by listening 'MozPhoneHangup' event. > > Clear key (editing keys, clear all typing text) > > - code: undefined > > - key: Clear > > Does "clear all typying text" mean canceling the composition of IME? or > Removing whole text including already committed text in <input> or > something? If it's the former, Escape is better, but I'd like to know the > scancode and Android keycode. > > Note that Clear key is very minor key on other platforms. So, web > application must not be handling it. > > However, if it doesn't work as like Esc key on PC, we shouldn't use Escape > to this key, though. > I'm not pretty sure the usage either. Seunghak and Jayachandra, could you help clarifying here? Thank you! > > 12-keys (numbers, ‘*’ and ‘#’) > > * numbers (0-9) > > - key: 0 / 1 / … > > Using actual inputting characters is correct. > > > - VirtualKeyCode: DOM_VK_NUMPAD0 / DOM_VK_NUMPAD0 / … > > This is what we need to be careful. I guess that this is okay. But I worry > about NumLock state (.getModifierState("NumLock")) and .location value. > Please be careful if you assume they are in Numpad. > I mapped them to Numpad because of the star key - I couldn't find 'DOM_VK_ASTERISK' at that time. Therefore I thought I should judged by the layout to map it as a Numpad, although I feel the regular DOM_VK_0 to DOM_VK_9 are best matches. I will vote for *not* using Numpad now to avoid NumLock problem. > > * pound key (‘#’) > > - key: # > > No problem. > > > - VirtualKeyCode: DOM_VK_HASH > > If you assume that this is also in Numpad, 0 might be better because there > is no such key. However, I guess that using DOM_VK_HASH shouldn't cause any > problem. So, let's use DOM_VK_HASH. However, you should be careful about > NumLock state and location. So I think it's no problem if we forget Numpad idea, right? > > > * star key (‘*’) > > - key: * > > - VirtualKeyCode: DOM_VK_MULTIPLY > > DOM_VK_MULTIPLY must be in Numpad. If it's not in Numpad logically, > DOM_VK_ASTERISK is better. > > Note that our .key mapping table is here: > http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMKeyName.h Thanks for the DOM_VK_ASTERISK suggestion, makes much more sense now!

(In reply to Evelyn Hung [:evelyn] from comment #11) > The foreground web application defines what it means, and shows labels on the screen. (Please see my attached image and hope my edit on the image expresses more.) See the attachment here.

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #9) > (In reply to Evelyn Hung [:evelyn] from comment #3) > > 1) I'm not sure if we start implementing DOM Lv3 events, should we follow > > key and code definition for these new keyboard events? > > Now, we have a lot of pending patches for conforming with the latest spec. > However, we still wait some spec bugs will be fixed. But we have no response > from WD of D3E for several months... At least for now, we should use only > already defined key values even if they are legacy name. > > See also bug 900372. > Thanks for the bug. I saw the first draft was written around year 2000... it's really a long process! > > 2) Could we extend key and code definition when there is no definition in > > the spec? like the Call and Call_End in our case. > > Basically, no. If we need new key values except Launch*, F* and Soft*. > However, if some of them necessary for the real product, *I* think that we > should define non-standard key names with "Moz" prefix. Got it. I try to not introduce many exceptions, and it seems the uncertain keys are: * Soft keys - if Soft1/Soft2 are not good choices. * Call/Call_End - I prefer MozPhoneCall and MozPhoneHangup. 'Power' for Call_End is acceptable, though. * Clear - not sure of it's usage.

Hi Evelyn and Masayuki, (In reply to Evelyn Hung [:evelyn] from comment #10) > (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #7) > > Oops, the table doesn't have all keys... I'd like to see all scancode values > > of other keys for judging .code mapping. > > I'm not sure if HW means scancode... LG people, could you confirm that? and > if they are scancode, could you also provide all scancode values for the > whole key set as I listed in this bug? Thanks! Answer for the questions. Q1. What does HW mean? is it scancode? Yes, It's scancode. HW values are Linux key code came to input device fd from keypad driver. As you know, B2G gets key events from android input reader which maps scancode with Android keycode as defined on key layout file. I should have written down "Scancode" instead of "HW" on the paper. Sorry for making you guys confused. Q2. Clear key could you help clarifying here? Clear key is being used like a back-space key on keyboard for Android keypad device. You might see "CLR" key on feature phones. On input text field or textarea, user can erase the last inserted character or delete all the typed text at once or continuously when user make long-press on clear key. So, We think VK_BACK_SPACE is good choice for Clear key. Q3. Wanna know all scancode values of other keys. Here are the scancode values. Pls, note that these scancode and keycode values are not defined for this VZW project just defined for LG Android keypad device which is currently being used as reference phone, LG Wine Smart, Evelyn may have one. I omit the scancode values of those keys mentioned on the attachment 8538011 [details] . Back key - scancode: 0x9E - keycode: BACK Clear key (editing keys, clear all typing text) - scancode: 0xAE - keycode: DEL App launch keys (application shortcuts) - scancode: 0x3B / 0x3C / 0x3D / 0x3E… - keycode: F1 / F2 / F3 / F4 Camera key - scancode: 0xD4 - keyCode: Camera Volume Keys (Multimedia keys) - scancode: 0x72 / 0x73 - keycode: VolumeDown / VolumeUp 12-keys (numbers, ‘*’ and ‘#’) * numbers (0-9) - scancode: 0x02 / 0x03 / 0x04 /… - keycode : 0 / 1 / 2 /… * pound key (‘#’) - scancode: 0x40 - keycode: POUND * star key (‘*’) - scancode: 0x3F - keycode: STAR If you need any information about this key codes please mark needinfo to me. Additionally, > > > CALL (depends on current viewing content, performs outgoing call initiation > > > or displaying Call History) > > > - key: Call (proposal) > > > > Mobile phone key names won't be defined in D3E, it would be defined in UI > > Events (a.k.a. D4E). > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=21121 > > Therefore, if we need to define this key name, my favorite is PhoneCall for > > clearing for what. And it should be MozPhoneCall for better compatibility > > with future's spec. > > > MozPhoneCall sounds good to me. Thanks! > > > > END (CALL_END, if there's a call in progress, end it; short-press behaves > > > ‘Home’, long-press behaves ‘Power’) > > > - key: Exit (defined in Media Controller Keys) > > > > I guess that Power is better because the Android keycode is KEYCODE_POWER. > > > It's a bit weird to listen to Power for hanging up a call... The key was overloaded for various usages in that old time. To be honest, > 'power' is the least attractive function on the keypad, it even doesn't have a label! (/me couldn't find a button to power-on the phone when > I got one.) > > Since we use 'MozPhoneCall' above, why don't we also follow the D4E spec and give it 'MozPhoneHangup'? On the other hand, power on/off > function is controlled by System app so I feel okay to make less sense here by listening 'MozPhoneHangup' event. We think that we can make dedicated key definitions for mobile keyboard and use that. If there is any possibility to fill out key definition to the http://www.w3.org/TR/DOM-Level-3-Events-code/#keyboard-mobile section, that's good to put "CALL", "ENDCALL" there with "PHONE" or "MOBILE" prefix. And define other key as well. But as Masayuki comments that the Mobile keys won't be define D3E, would be defined in D4E, and he prefer the "PhoneCall" and "PhoneHangup" so it's okay to use the "Call" and "Hangup" with "Phone_". The "END" key always come together with power key functionality on Keypad device and usually keypad mobile device doesn't have power key separately. Because of too many keys??? Merry Christmas. :)

Sorry for the delay to check this. I'll be offline until 1/7 (JST). Please wait if you have additional questions. (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #9) > (In reply to Evelyn Hung [:evelyn] from comment #3) > > 1) I'm not sure if we start implementing DOM Lv3 events, should we follow > > key and code definition for these new keyboard events? > > Now, we have a lot of pending patches for conforming with the latest spec. > However, we still wait some spec bugs will be fixed. But we have no response > from WD of D3E for several months... At least for now, we should use only > already defined key values even if they are legacy name. > > See also bug 900372. FYI: We will land the pending patches as soon as possible because we wait response from WG of D3E enough long but still no response. (i.e., starting Gecko 37, almost of all key names will conform with the latest draft) (In reply to Evelyn Hung [:evelyn] from comment #11) > (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #8) > > (In reply to Evelyn Hung [:evelyn] from comment #1) > > > > > Soft Menu keys (two keys: left and right, can be flexibly programmable as > > > application’s context) > > > - key: Soft1 / Soft2 > > > > This is difficult. I guess that using these values doesn't cause any > > compatibility problem with web applications at least for now. However, web > > applications cannot *guess* the keys what users expected. Therefore, it > > might be better to map key values which represent typical purpose of the > > keys. I'm not sure the actual usage of the keys, though. > > > > The foreground web application defines what it means, and shows labels on > the screen. (Please see my attached image and hope my edit on the image > expresses more.) > The two keys provide flexibility to applications to use them as a shortcut > for some purposes. Usually he actual usages are: showing more 'options', > entering 'edit' mode or 'exit'... However, we can't assume it's real usage, > it's up to the foreground app. Hmm, okay. Then, Soft1 and Soft2 might be the best if we need to chose the names from current spec. > I feel it's new to this spec, so maybe Soft1 or Soft2 aren't the best match, > and the description on the spec 'General purpose virtual function key' is > unclear to me. Maybe, maybe not. I think "General purpose virtual function key" means that they are various keys which cannot be defined by the spec because of keeping the tables small as far as possible. I think that Soft[0-9]+ keys shouldn't be handled by public web application. They must be useful if application developers can limit the device/environment of their users. E.g., embedded applications of a device or intranet use. > MozPhoneCall sounds good to me. Thanks! Yeah, and it might be better to check the key name without prefix in embedded applications. And also, I strongly recommend that key names shouldn't be compared with string literal directly because the key names might be renamed again in future release. For better ability to maintain, application developers should use constants. E.g., const kKeyNamePhoneCall = "MozPhoneCall"; ... if (aEvent.key == kKeyNamePhoneCall) { // do something. } > > > END (CALL_END, if there's a call in progress, end it; short-press behaves > > > ‘Home’, long-press behaves ‘Power’) > > > - key: Exit (defined in Media Controller Keys) > > > > I guess that Power is better because the Android keycode is KEYCODE_POWER. > > > > It's a bit weird to listen to Power for hanging up a call... The key was > overloaded for various usages in that old time. To be honest, 'power' is the > least attractive function on the keypad, it even doesn't have a label! (/me > couldn't find a button to power-on the phone when I got one.) According to the motivation of KeyboardEvent.key, the value should be set for *current* purpose. I.e., it should depend on the situations. I.e., only while the phone is calling, use "MozPhoneHangup". But when it's used for power off, "Power" or "PowerOff" should be used. However, this is an ideal behavior, I guess that it's unrealistic. > Since we use 'MozPhoneCall' above, why don't we also follow the D4E spec and > give it 'MozPhoneHangup'? On the other hand, power on/off function is > controlled by System app so I feel okay to make less sense here by listening > 'MozPhoneHangup' event. Okay, then, "MozPhoneHangup" might be useful. However, I also feel strange that "MozPhoneHangup" key works as Home key of smartphone. > > > 12-keys (numbers, ‘*’ and ‘#’) > > > * numbers (0-9) > > > - key: 0 / 1 / … > > > > Using actual inputting characters is correct. > > > > > - VirtualKeyCode: DOM_VK_NUMPAD0 / DOM_VK_NUMPAD0 / … > > > > This is what we need to be careful. I guess that this is okay. But I worry > > about NumLock state (.getModifierState("NumLock")) and .location value. > > Please be careful if you assume they are in Numpad. > > > > I mapped them to Numpad because of the star key - I couldn't find > 'DOM_VK_ASTERISK' at that time. Therefore I thought I should judged by the > layout to map it as a Numpad, although I feel the regular DOM_VK_0 to > DOM_VK_9 are best matches. I will vote for *not* using Numpad now to avoid > NumLock problem. Sounds good to me. > > > * pound key (‘#’) > > > - key: # > > > > No problem. > > > > > - VirtualKeyCode: DOM_VK_HASH > > > > If you assume that this is also in Numpad, 0 might be better because there > > is no such key. However, I guess that using DOM_VK_HASH shouldn't cause any > > problem. So, let's use DOM_VK_HASH. However, you should be careful about > > NumLock state and location. > > So I think it's no problem if we forget Numpad idea, right? Yes. > > > * star key (‘*’) > > > - key: * > > > - VirtualKeyCode: DOM_VK_MULTIPLY > > > > DOM_VK_MULTIPLY must be in Numpad. If it's not in Numpad logically, > > DOM_VK_ASTERISK is better. > > > > Note that our .key mapping table is here: > > http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMKeyName.h > > Thanks for the DOM_VK_ASTERISK suggestion, makes much more sense now! You're welcome. I'll check next comments later.

(In reply to Jinho Hwang [:jeffhwang] from comment #14) > Q2. Clear key could you help clarifying here? > Clear key is being used like a back-space key on keyboard for Android > keypad device. > You might see "CLR" key on feature phones. > On input text field or textarea, user can erase the last inserted > character or delete all the typed text at once or continuously when user > make long-press on clear key. > So, We think VK_BACK_SPACE is good choice for Clear key. Yeah, sounds good. I have a question. Can user connect USB keyboard or Bluetooth keyboard to the simple phone? If it's possible, I guess each keys on the phone is mapped to one of the keys on PC keyboard. If so, considering .key value mapping from PC keyboard might be better way. > Q3. Wanna know all scancode values of other keys. > Here are the scancode values. > Pls, note that these scancode and keycode values are not defined for > this VZW project > just defined for LG Android keypad device which is currently being used > as reference phone, LG Wine Smart, Evelyn may have one. > > I omit the scancode values of those keys mentioned on the attachment > 8538011 [details] . > > > Back key > - scancode: 0x9E > - keycode: BACK Hmm, it maps "BrowserBack" for .code... http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#699 > Clear key (editing keys, clear all typing text) > - scancode: 0xAE > - keycode: DEL It's currently not mapped on Android platforms (including Firefox OS). > App launch keys (application shortcuts) > - scancode: 0x3B / 0x3C / 0x3D / 0x3E… > - keycode: F1 / F2 / F3 / F4 They are F1 - F4. http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#566 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#571 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#576 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#581 > Camera key > - scancode: 0xD4 > - keyCode: Camera It's currently not mapped on Android platforms. > Volume Keys (Multimedia keys) > - scancode: 0x72 / 0x73 > - keycode: VolumeDown / VolumeUp They are VolumeDown and VolumeUp http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#774 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#784 > 12-keys (numbers, ‘*’ and ‘#’) > * numbers (0-9) > - scancode: 0x02 / 0x03 / 0x04 /… > - keycode : 0 / 1 / 2 /… If 0x02 is 1 and 0x0B is 0, they are mapped to 0-9 in standard position (not numpad). Do you really map 0 key to 0x02?? http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#92 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#97 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#102 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#107 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#112 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#117 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#122 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#127 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#132 http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#87 > * pound key (‘#’) > - scancode: 0x40 > - keycode: POUND Hmm, that's F6... http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#591 > * star key (‘*’) > - scancode: 0x3F > - keycode: STAR And that's F5... http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#586 We have two choices, we will use another map only when Firefox OS is built for the phone. Or, we will use current mapping. If we chose the former, USB/Bluetooth keyboards shouldn't be able to connected to the phone... Can the scancode be changed in driver level? > The "END" key always come together with power key functionality on Keypad > device and > usually keypad mobile device doesn't have power key separately. Because of > too many keys??? As I said, .key value should be flexible and depend on the situations if it's possible. However, it's difficult, we need to decide the best value from: * What's the usual function of the key (in all applications)? * If long key press behavior is implemented in software level, short key press behavior is better. * If USB/Bluetooth keyboard can be connected to the phone, which key is mapped to a key on the phone?

I'd like to say one important thing about this bug. Probably, this is the first case in the world to design D3E KeyboardEvent for simple phone. So, the mapping is very very important for similar devices (including other platforms) which are released in the future!

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #16) Hi, Masayuki. I'd like to start answering to the most important question one. > We have two choices, we will use another map only when Firefox OS is built > for the phone. Or, we will use current mapping. If we chose the former, > USB/Bluetooth keyboards shouldn't be able to connected to the phone... > > Can the scancode be changed in driver level? Yes, we can change the scancode in the driver level. And, we don't have to use current mapping which is designed for LG Android feature phone with keypad. > (In reply to Jinho Hwang [:jeffhwang] from comment #14) > > Q2. Clear key could you help clarifying here? > > Clear key is being used like a back-space key on keyboard for Android > > keypad device. > > You might see "CLR" key on feature phones. > > On input text field or textarea, user can erase the last inserted > > character or delete all the typed text at once or continuously when user > > make long-press on clear key. > > So, We think VK_BACK_SPACE is good choice for Clear key. > > Yeah, sounds good. I have a question. Can user connect USB keyboard or > Bluetooth keyboard to the simple phone? Currently No. I guess that FxOS will support those input devices in the near future. The HID will be enabled on v3.0 and Keyboard and mouse can be enabled for FxOS on Raspberry Pi or pandaboard. > If it's possible, I guess each keys > on the phone is mapped to one of the keys on PC keyboard. If so, considering > .key value mapping from PC keyboard might be better way. Yeah, sounds good. Only, except those keys not on the PC keyboard such as CALL, ENDCALL, POUND, STAR and DPAD_CENTER. > > Clear key (editing keys, clear all typing text) > > - scancode: 0xAE > > - keycode: DEL > > It's currently not mapped on Android platforms (including Firefox OS). I think that the scancode for Clear key should be changed to 0x000E(KEY_BACKSPACE/KEYCODE_DEL) mapped with BACKSPACE http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName.h?rev=ccd53912eb4c#67 > > App launch keys (application shortcuts) > > - scancode: 0x3B / 0x3C / 0x3D / 0x3E… > > - keycode: F1 / F2 / F3 / F4 > > They are F1 - F4. > > > Camera key > > - scancode: 0xD4 > > - keyCode: Camera > > It's currently not mapped on Android platforms. Do you think it's okay map Function keys to LaunchApp Shortcuts? If so, we can also use F? key for the LaunchCamera key. > > 12-keys (numbers, ‘*’ and ‘#’) > > * numbers (0-9) > > - scancode: 0x02 / 0x03 / 0x04 /… > > - keycode : 0 / 1 / 2 /… > > If 0x02 is 1 and 0x0B is 0, they are mapped to 0-9 in standard position (not > numpad). Do you really map 0 key to 0x02?? It can be changed, the 0-9 key scancodes to numpad values, if you wish. As you know, the numpad keys are also not perfectly matched with 12 keys on phone. So, I think that we need to choose one from the standard and numpad, or define new keys of mobile for http://www.w3.org/TR/DOM-Level-3-Events-code/#keyboard-mobile > > * pound key (‘#’) > > - scancode: 0x40 > > - keycode: POUND > > Hmm, that's F6... > http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName. > h?rev=ccd53912eb4c#591 > > > * star key (‘*’) > > - scancode: 0x3F > > - keycode: STAR > > And that's F5... > http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName. > h?rev=ccd53912eb4c#586 Yeah, these are not a best match. we should find suitable keys for the Pound and Star key. On the Android side, it was mapped with KEY_SHARP(0x00e4) and KEY_STAR(0x00e3) of LKC but those are artifact same as SOFT1, SOFT2 and DPAD_CENTER key. Because of inconsistent access with HID or used non-standard Linux key codes. https://source.android.com/devices/input/keyboard-devices.html

Sorry for the delay to reply. I'll check this week again.

I'm very sorry for the delay, again. (In reply to Jinho Hwang [:jeffhwang] from comment #18) > (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #16) > > We have two choices, we will use another map only when Firefox OS is built > > for the phone. Or, we will use current mapping. If we chose the former, > > USB/Bluetooth keyboards shouldn't be able to connected to the phone... > > > > Can the scancode be changed in driver level? > > Yes, we can change the scancode in the driver level. > And, we don't have to use current mapping which is designed for LG Android > feature phone with keypad. Okay, then, our code cannot build only for specific devices. So, aligning the scancode to our mapping in driver level is the best approach to change the mapping. > > (In reply to Jinho Hwang [:jeffhwang] from comment #14) > > > Q2. Clear key could you help clarifying here? > > > Clear key is being used like a back-space key on keyboard for Android > > > keypad device. > > > You might see "CLR" key on feature phones. > > > On input text field or textarea, user can erase the last inserted > > > character or delete all the typed text at once or continuously when user > > > make long-press on clear key. > > > So, We think VK_BACK_SPACE is good choice for Clear key. > > > > Yeah, sounds good. I have a question. Can user connect USB keyboard or > > Bluetooth keyboard to the simple phone? > > Currently No. I guess that FxOS will support those input devices in the near > future. > The HID will be enabled on v3.0 and Keyboard and mouse can be enabled for > FxOS on Raspberry Pi or pandaboard. Okay, thanks. If FxOS will support HID or Bluetooth, can your simplephone connect them? (I'm not asking if LG will support it software level, my question is that it has a potential to connect them in hardware level) > > If it's possible, I guess each keys > > on the phone is mapped to one of the keys on PC keyboard. If so, considering > > .key value mapping from PC keyboard might be better way. > > Yeah, sounds good. Only, except those keys not on the PC keyboard such as > CALL, ENDCALL, POUND, STAR and DPAD_CENTER. Sure. But Enter might be good for DPAD_CENTER if it works as so. > > > Clear key (editing keys, clear all typing text) > > > - scancode: 0xAE > > > - keycode: DEL > > > > It's currently not mapped on Android platforms (including Firefox OS). > > I think that the scancode for Clear key should be changed to > 0x000E(KEY_BACKSPACE/KEYCODE_DEL) mapped with BACKSPACE > http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName. > h?rev=ccd53912eb4c#67 Does the key work as Backspace key? E.g., removes previous character of caret? If so, I think that it's the best approach. > > > Camera key > > > - scancode: 0xD4 > > > - keyCode: Camera > > > > It's currently not mapped on Android platforms. > > Do you think it's okay map Function keys to LaunchApp Shortcuts? > If so, we can also use F? key for the LaunchCamera key. Basically, we don't want to add #ifdef for specific devices. If there is a common scancode for camera button on Android phones, using it is the best. For Camera button, D3E key spec defines "Camera" value: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-key.html#key-Camera So, LaunchCamera isn't good. Although, it's not illegal. > > > 12-keys (numbers, ‘*’ and ‘#’) > > > * numbers (0-9) > > > - scancode: 0x02 / 0x03 / 0x04 /… > > > - keycode : 0 / 1 / 2 /… > > > > If 0x02 is 1 and 0x0B is 0, they are mapped to 0-9 in standard position (not > > numpad). Do you really map 0 key to 0x02?? > > It can be changed, the 0-9 key scancodes to numpad values, if you wish. Yeah, I hope they are mapped to 0-9 of standard position's or numpad's keys. If you map them to numpad's keys, when they are pressed, NumLock state must be true (KeyboardEvent.getModifierState("NumLock") must be true). So, using standard position's 0 - 9 keys are simpler. I filed a spec bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27991 > As you know, the numpad keys are also not perfectly matched with 12 keys on > phone. > So, I think that we need to choose one from the standard and numpad, or > define new keys of mobile for > http://www.w3.org/TR/DOM-Level-3-Events-code/#keyboard-mobile Yeah, it's too bad. I filed a spec bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27990 I have a question. Do those keys insert "#" or "*" when user presses it when text input field has focus? If not, they should have specific key names. Android spec has specific keycode values? > > > * pound key (‘#’) > > > - scancode: 0x40 > > > - keycode: POUND > > > > Hmm, that's F6... > > http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName. > > h?rev=ccd53912eb4c#591 > > > > > * star key (‘*’) > > > - scancode: 0x3F > > > - keycode: STAR > > > > And that's F5... > > http://mxr.mozilla.org/mozilla-central/source/widget/NativeKeyToDOMCodeName. > > h?rev=ccd53912eb4c#586 > > Yeah, these are not a best match. we should find suitable keys for the Pound > and Star key. > On the Android side, it was mapped with KEY_SHARP(0x00e4) and > KEY_STAR(0x00e3) of LKC but those are artifact same as SOFT1, SOFT2 and > DPAD_CENTER key. Because of inconsistent access with HID or used > non-standard Linux key codes. > https://source.android.com/devices/input/keyboard-devices.html Hmm, sounds bad.

Forgot to mark needinfo? for the previous message. And I have a question. Who decides Android keycode from scancode? Driver? or OS maps it from scancode?

We're still discussing, all digits keys should be assumed as keys in Numpad. I.e., .code value of "1" should be Numpad1. However, WG members said that we don't need to hack the NumLock state in this case. Similarly, if scancode values for "#" and "*" are mapped to unused values (on Android platform), they should be mapped such values and these values should be "NumpadHash" and "NumpadAsterisk". W3E WG's pending issues is that if they work as non-printable key, they may need new .key values. (If they input text when <input> has focus, .key value is the inputting text.)

Hi Masayuki, sorry for the delay. (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #21) > Forgot to mark needinfo? for the previous message. > > > And I have a question. Who decides Android keycode from scancode? Driver? or > OS maps it from scancode? It is decided by key layout file in Android device configuration stack. e.g) https://www.codeaurora.org/cgit/quic/la/device/htc/dream/tree/trout-keypad.kl the Linux key codes are defined in https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/include/linux/input.h?id=AU_LINUX_ANDROID_KK_3.5.04.04.04.003.593

Sorry for the long delay. D3E WG have decided the rules of simplephone's key/code value spec: * .code values of 0-9 keys should be Numpad0 - Numpad9. * .code value of # key should be NumpadHash. * .code value of * key should be NumpadStar. https://dvcs.w3.org/hg/dom3events/rev/b1ba98eac6aa https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-code.html#h-key-numpad-section The latter is out of scope of USB HID spec, if it cannot be mapped easy, let me know.

Thank you, :masayuki! Hi Jeff, is this definition good to you? do we have any issue left here? Thanks.

(In reply to Evelyn Hung [:evelyn] from comment #25) > Thank you, :masayuki! > > Hi Jeff, is this definition good to you? do we have any issue left here? > Thanks. Thank you! Masayuki and Evelyn! This is great :) I think we still left other keys used in Mobile devices such as Call/EndCall/SoftKey(Left/Right) and so on. I hope that these keys are also discussed on this bug soon. https://www.w3.org/Bugs/Public/show_bug.cgi?id=27996 Thank you again~ :)

Can we either make this public or create a public sub-bug blocking this one?

Hey Vance, This is essential features we'll need for 2.2R. Could you please confirm the ETA (9/25 or earlier) with partner?

Hi Jinyoon, Per comment 28, Would you please kindly provide your confirmation and feedback on this request ? Will this work be able to be done(landed on 2.2R) by the end of Sep ? Thank you very much !!

For comment 27, I agree to make it public. I think this bug needs not be confidential. And for comment 28, this work will be done on the given schedule.

Hi Jinyoon, As we discussed before, May you kindly please start uploading your work on spatial navigation? Then we could start the review process to make it ready by the end of Sep . Thank you very much for your support !

(In reply to Rachelle Yang [:ryang][ryang@mozilla.com] from comment #29) > Hi Jinyoon, > > Per comment 28, Would you please kindly provide your confirmation and > feedback on this request ? > Will this work be able to be done(landed on 2.2R) by the end of Sep ? > > Thank you very much !! Hi,Rachlle, I have upload about the DOM key mapping patch : Soft1, Soft2 and PhoneCall key Who is the reviewer for this patch? Thanks for your help.

(In reply to hansu9866 from comment #32) > (In reply to Rachelle Yang [:ryang][ryang@mozilla.com] from comment #29) > > Hi Jinyoon, > > > > Per comment 28, Would you please kindly provide your confirmation and > > feedback on this request ? > > Will this work be able to be done(landed on 2.2R) by the end of Sep ? > > > > Thank you very much !! > > Hi,Rachlle, > > I have upload about the DOM key mapping patch > : Soft1, Soft2 and PhoneCall key > > Who is the reviewer for this patch? > Thanks for your help. Please set r? to mwu, thanks.

DOM Key Mapping patch :Soft1,Soft2 and Call keys

Comment on attachment 8662748 [details] [diff] [review] dom_key_mapping_part1.patch Review of attachment 8662748 [details] [diff] [review]: ----------------------------------------------------------------- Hi, mwu Could you review these patch for DOM key mapping?

Comment on attachment 8662748 [details] [diff] [review] dom_key_mapping_part1.patch >+DEFINE_KEYNAME_WITH_SAME_NAME(PhoneCall) >+DEFINE_KEYNAME_WITH_SAME_NAME(SoftLeft) >+DEFINE_KEYNAME_WITH_SAME_NAME(SoftRight) If you want to add new key values without "Moz" prefix, you should suggest to the WG and registered to the key value spec before we land this. https://w3c.github.io/DOM-Level-3-Events-key/ If it's okay to use "Moz" prefix, you should add them to here: http://mxr.mozilla.org/mozilla-central/source/dom/events/KeyNameList.h#28 >-DEFINE_VK_INTERNAL(_WIN_OEM_CLEAR) >+DEFINE_VK_INTERNAL(_WIN_OEM_CLEAR), >+DEFINE_VK_INTERNAL(_PHONECALL), >+DEFINE_VK_INTERNAL(_SOFT1), >+DEFINE_VK_INTERNAL(_SOFT2) We don't want to add legacy keyCode value anymore. The new keys should be distinguished by .key value. >+ const unsigned long DOM_VK_SOFT1 = 0x100; >+ const unsigned long DOM_VK_SOFT2 = 0x101; >+ const unsigned long DOM_VK_PHONECALL = 0x102; Ditto. >+ const unsigned long DOM_VK_SOFT1 = 0x100; >+ const unsigned long DOM_VK_SOFT2 = 0x101; >+ const unsigned long DOM_VK_PHONECALL = 0x102; Ditto.

Comment on attachment 8662748 [details] [diff] [review] dom_key_mapping_part1.patch If you are only modifying the kKeyMapping table in widget/gonk, masayuki's review is sufficient.

Thank you! Masayuki and Michael! I add inline comment and some questions. (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) (Offline: 9/21-23, prehaps, not so active: 9/24, 9/25) from comment #36) > Comment on attachment 8662748 [details] [diff] [review] > dom_key_mapping_part1.patch > > >+DEFINE_KEYNAME_WITH_SAME_NAME(PhoneCall) > >+DEFINE_KEYNAME_WITH_SAME_NAME(SoftLeft) > >+DEFINE_KEYNAME_WITH_SAME_NAME(SoftRight) > > If you want to add new key values without "Moz" prefix, you should suggest > to the WG and registered to the key value spec before we land this. > https://w3c.github.io/DOM-Level-3-Events-key/ > > If it's okay to use "Moz" prefix, you should add them to here: > http://mxr.mozilla.org/mozilla-central/source/dom/events/KeyNameList.h#28 > I think that it's okay to use "Moz" prefix. > >-DEFINE_VK_INTERNAL(_WIN_OEM_CLEAR) > >+DEFINE_VK_INTERNAL(_WIN_OEM_CLEAR), > >+DEFINE_VK_INTERNAL(_PHONECALL), > >+DEFINE_VK_INTERNAL(_SOFT1), > >+DEFINE_VK_INTERNAL(_SOFT2) > > We don't want to add legacy keyCode value anymore. The new keys should be > distinguished by .key value. > > >+ const unsigned long DOM_VK_SOFT1 = 0x100; > >+ const unsigned long DOM_VK_SOFT2 = 0x101; > >+ const unsigned long DOM_VK_PHONECALL = 0x102; > > Ditto. > > >+ const unsigned long DOM_VK_SOFT1 = 0x100; > >+ const unsigned long DOM_VK_SOFT2 = 0x101; > >+ const unsigned long DOM_VK_PHONECALL = 0x102; > > Ditto. Ok,But How to make a these changes?

> Ok,But How to make a these changes? keyCode value of the new keys should be 0. But it shouldn't be a matter since event listener can check .key value instead.

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) (Offline: 9/21-23, prehaps, not so active: 9/24, 9/25) from comment #39) > > Ok,But How to make a these changes? > > keyCode value of the new keys should be 0. But it shouldn't be a matter > since event listener can check .key value instead. Thank you! Masayuki I upload dom_key_mapping_part1_v2.patch

Comment on attachment 8664175 [details] [diff] [review] dom_key_mapping_part1_v2.patch > /****************************************************************************** > * Our Internal Key Values (must have "Moz" prefix) > *****************************************************************************/ > DEFINE_KEYNAME_INTERNAL(PrintableKey, "MozPrintableKey") > DEFINE_KEYNAME_INTERNAL(HomeScreen, "MozHomeScreen") >- >+DEFINE_KEYNAME_INTERNAL(PhoneCall, "MozPhoneCall") >+DEFINE_KEYNAME_INTERNAL(SoftLeft, "MozSoftLeft") >+DEFINE_KEYNAME_INTERNAL(SoftRight, "MozSoftRight") nit: Don't remove the empty line at the last of this section. And you must use old tree. There must be a definition of CameraFocusAdjust below HomeScreen. > // WakeUp > KEY_MAP_GTK (WakeUp, GDK_WakeUp) > KEY_MAP_QT (WakeUp, Qt::Key_WakeUp) > >+// Mobile Keypad : Call + SoftMenu 1, 2 >+KEY_MAP_ANDROID (PhoneCall, AKEYCODE_CALL) >+KEY_MAP_ANDROID (SoftLeft, AKEYCODE_SOFT_LEFT) >+KEY_MAP_ANDROID (SoftRight, AKEYCODE_SOFT_RIGHT) Please move the mapping below "CameraFocusAdjust". And please define each mapping per key. I.e.,: // PhoneCall KEY_MAP_ANDROID (PhoneCall, AKEYCODE_CALL) // SoftLeft KEY_MAP_ANDROID (SoftLeft, AKEYCODE_SOFT_LEFT) // SoftRight KEY_MAP_ANDROID (SoftRight, AKEYCODE_SOFT_RIGHT) because other platforms may need to map them to their virtual key codes. All of them are nits, but I'd like to check the new patch again.

Thanks for your help. It was Korean Thanksgiving Day. So I'm late for new patch. 1) According to your guide, I modify the keyname files. 2) Also, as your comments "because other platforms may need to map them to their virtual key codes." I modify the key code related files. But, It need to your guide because of key code value and source code position in the files. Please review the dom_key_mapping_part_v3.patch

Comment on attachment 8668273 [details] [diff] [review] dom_key_mapping_part_v3.patch >diff --git a/dom/events/VirtualKeyCodeList.h b/dom/events/VirtualKeyCodeList.h >index cca6489..5e82ed9 100644 >--- a/dom/events/VirtualKeyCodeList.h >+++ b/dom/events/VirtualKeyCodeList.h >@@ -215,13 +215,16 @@ DEFINE_VK_INTERNAL(_WIN_OEM_ENLW), > DEFINE_VK_INTERNAL(_WIN_OEM_BACKTAB), > > DEFINE_VK_INTERNAL(_ATTN), > DEFINE_VK_INTERNAL(_CRSEL), > DEFINE_VK_INTERNAL(_EXSEL), > DEFINE_VK_INTERNAL(_EREOF), > DEFINE_VK_INTERNAL(_PLAY), > DEFINE_VK_INTERNAL(_ZOOM), > DEFINE_VK_INTERNAL(_PA1), >-DEFINE_VK_INTERNAL(_WIN_OEM_CLEAR) >+DEFINE_VK_INTERNAL(_WIN_OEM_CLEAR), >+DEFINE_VK_INTERNAL(_PHONECALL), >+DEFINE_VK_INTERNAL(_SOFT1), >+DEFINE_VK_INTERNAL(_SOFT2) > > #undef DEFINE_VK_INTERNAL > #undef DEFINE_VK_INTERNAL2 >diff --git a/dom/interfaces/events/nsIDOMKeyEvent.idl b/dom/interfaces/events/nsIDOMKeyEvent.idl >index b9dd3a3..681c54c 100644 >--- a/dom/interfaces/events/nsIDOMKeyEvent.idl >+++ b/dom/interfaces/events/nsIDOMKeyEvent.idl >@@ -219,18 +219,22 @@ interface nsIDOMKeyEvent : nsIDOMUIEvent > const unsigned long DOM_VK_EREOF = 0xF9; > const unsigned long DOM_VK_PLAY = 0xFA; > const unsigned long DOM_VK_ZOOM = 0xFB; > const unsigned long DOM_VK_PA1 = 0xFD; > > // OEM specific virtual keyCode of Windows should pass through DOM keyCode > // for compatibility with the other web browsers on Windows. > const unsigned long DOM_VK_WIN_OEM_CLEAR = 0xFE; > >+ const unsigned long DOM_VK_SOFT1 = 0x100; >+ const unsigned long DOM_VK_SOFT2 = 0x101; >+ const unsigned long DOM_VK_PHONECALL = 0x102; >+ > readonly attribute unsigned long charCode; > readonly attribute unsigned long keyCode; > > readonly attribute boolean altKey; > readonly attribute boolean ctrlKey; > readonly attribute boolean shiftKey; > readonly attribute boolean metaKey; > > void initKeyEvent(in DOMString typeArg, >diff --git a/dom/webidl/KeyEvent.webidl b/dom/webidl/KeyEvent.webidl >index 37ff7fc..398c373 100644 >--- a/dom/webidl/KeyEvent.webidl >+++ b/dom/webidl/KeyEvent.webidl >@@ -218,18 +218,22 @@ interface KeyEvent > const unsigned long DOM_VK_EREOF = 0xF9; > const unsigned long DOM_VK_PLAY = 0xFA; > const unsigned long DOM_VK_ZOOM = 0xFB; > const unsigned long DOM_VK_PA1 = 0xFD; > > // OEM specific virtual keyCode of Windows should pass through DOM keyCode > // for compatibility with the other web browsers on Windows. > const unsigned long DOM_VK_WIN_OEM_CLEAR = 0xFE; > >+ const unsigned long DOM_VK_SOFT1 = 0x100; >+ const unsigned long DOM_VK_SOFT2 = 0x101; >+ const unsigned long DOM_VK_PHONECALL = 0x102; >+ > [Throws] > void initKeyEvent(DOMString type, > boolean canBubble, > boolean cancelable, > Window? view, > boolean ctrlKey, > boolean altKey, > boolean shiftKey, > boolean metaKey, >diff --git a/widget/gonk/GonkKeyMapping.h b/widget/gonk/GonkKeyMapping.h >index 04bd178..503ee78 100644 >--- a/widget/gonk/GonkKeyMapping.h >+++ b/widget/gonk/GonkKeyMapping.h >@@ -19,23 +19,23 @@ > #include "libui/android_keycodes.h" > #include "mozilla/EventForwards.h" > > namespace mozilla { > namespace widget { > > /* See libui/KeycodeLabels.h for the mapping */ > static const unsigned long kKeyMapping[] = { > 0, >- 0, // SOFT_LEFT >- 0, // SOFT_RIGHT >+ NS_VK_SOFT1, // SOFT_LEFT >+ NS_VK_SOFT2, // SOFT_RIGHT > NS_VK_HOME, // HOME > 0, // BACK >- 0, // CALL >+ NS_VK_PHONECALL, // CALL > NS_VK_SLEEP, // ENDCALL > NS_VK_0, > NS_VK_1, > NS_VK_2, > NS_VK_3, > NS_VK_4, > NS_VK_5, > NS_VK_6, > NS_VK_7, No, as I said, you shouldn't define new keyCode. Please keep them 0. The .key value part looks good to me, though.

> No, as I said, you shouldn't define new keyCode. Please keep them 0. Sorry, I don't understand exactly what is the mean? 1) The keycode related files are don't need to change right? (VirtualKeyCodeList.h, nsIDOMKeyEvent.idl, KeyEvent.webidl,GonkKeyMapping.h) 2) Or, If not These new key code values have to set 0 on nsIDOMKeyEvent.idl and KeyEvent.webidl fies right? const unsigned long DOM_VK_SOFT1 = 0x00; const unsigned long DOM_VK_SOFT2 = 0x00; const unsigned long DOM_VK_PHONECALL = 0x00;

(In reply to hansu9866 from comment #46) > > No, as I said, you shouldn't define new keyCode. Please keep them 0. > > Sorry, I don't understand exactly what is the mean? > > 1) The keycode related files are don't need to change right? > (VirtualKeyCodeList.h, nsIDOMKeyEvent.idl, > KeyEvent.webidl,GonkKeyMapping.h) Right. Your previous patch removed those changes, but came back with current patch.

> Right. Your previous patch removed those changes, but came back with current > patch. OK, Thank you! I attach DOMKeyMapping_soft1_soft2_phonecall.patch

this failed to apply to 2.2r, could you take a look, thanks! dding 1112712 to series file renamed 1112712 -> DOMKeyMapping_soft1_soft2_phonecall.patch applying DOMKeyMapping_soft1_soft2_phonecall.patch patching file dom/events/KeyNameList.h Hunk #1 FAILED at 24 1 out of 1 hunks FAILED -- saving rejects to file dom/events/KeyNameList.h.rej patching file widget/NativeKeyToDOMKeyName.h Hunk #1 FAILED at 1298 1 out of 1 hunks FAILED -- saving rejects to file widget/NativeKeyToDOMKeyName.h.rej patch failed, unable to continue (try -v) patch failed, rejects left in working directory errors during apply, please fix and refresh DOMKeyMapping_soft1_soft2_phonecall.patch

This patch is prepared for master version. Between mater and v2.2r, some key definition have diff.(ex. CameraFocusAdjust and refer comment42) If need i will prepare the patch for v2.2r Mr. Masayuki~ How about your opinion on applying version?

This has caused bustage like this /builds/slave/b2g-in-and-x86-000000000000000/build/src/widget/android/nsWindow.cpp:1479:9: error: duplicate case value /builds/slave/b2g-in-and-x86-000000000000000/build/src/widget/NativeKeyToDOMKeyName.h:1312:1: error: previously used here /builds/slave/b2g-in-and-x86-000000000000000/build/src/widget/android/nsWindow.cpp:1480:9: error: duplicate case value /builds/slave/b2g-in-and-x86-000000000000000/build/src/widget/NativeKeyToDOMKeyName.h:1315:1: error: previously used here /builds/slave/b2g-in-and-x86-000000000000000/build/src/widget/android/nsWindow.cpp:1481:9: error: duplicate case value /builds/slave/b2g-in-and-x86-000000000000000/build/src/widget/NativeKeyToDOMKeyName.h:1309:1: error: previously used here

Backed out in https://hg.mozilla.org/integration/b2g-inbound/rev/825f49208b80

patch about dom key mapping for soft1,soft2,call keys and fix build error firefox on android

Comment on attachment 8670618 [details] [diff] [review] DomKeyMapping_and_fix_build_error.patch Review of attachment 8670618 [details] [diff] [review]: ----------------------------------------------------------------- This patch is only updated for fixing Fennec build error, should carry r+ directly.

Comment on attachment 8675470 [details] [diff] [review] patch_for_v2.2r.patch - soft1, soft2 and phonecall for v2.2r Unfortunately I don't have the privilege to review these code. However, this is just a patch rebase. Should be able to carry r+.

@Wesley, partner already prepared the v2.2r patch for landing. Could you kindly guide he on the 2.2r landing process?

(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #61) > @Wesley, partner already prepared the v2.2r patch for landing. Could you > kindly guide he on the 2.2r landing process? Awesome. checkin-needed keyword added so it's good to go. Refer to https://wiki.mozilla.org/Release_Management/FirefoxOS/2_2_R_Schedule#Patch_Uplifts