1112712 - DOM key and code mapping for simple phone hardware keys

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Evelyn Hung]

Attachment: Proposal from LG

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 ‘#’)

Comment 1

[Evelyn Hung]

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

Comment 2

[Evelyn Hung]

[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

Comment 3

[Evelyn Hung]

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.

Comment 4

[Evelyn Hung]

Attachment: Proposal from LG

Comment 5

[Evelyn Hung]

(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].

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(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

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(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.

Comment 10

[Evelyn Hung]

(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!

Comment 11

[Evelyn Hung]

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!

Comment 12

[Evelyn Hung]

Attachment: Soft keys illustration

(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.

Comment 13

[Evelyn Hung]

(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.

Comment 14

[Jinho Hwang [:jeffhwang]]

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. :)

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(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?

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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!

Comment 18

[Jinho Hwang [:jeffhwang]]

(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

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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?

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.)

Comment 23

[Jinho Hwang [:jeffhwang]]

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

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 25

[Evelyn Hung]

Thank you, :masayuki!

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

Comment 26

[Jinho Hwang [:jeffhwang]]

(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~ :)

Comment 27

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

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

Comment 28

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

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

Comment 29

[Rachelle Yang [:ryang][[e-mail]]]

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 !!

Comment 30

[Jinyoon]

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.

Comment 31

[Rachelle Yang [:ryang][[e-mail]]]

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 !

Comment 32

[hansu9866]

(In reply to Rachelle Yang [:ryang][[e-mail]] 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.

Comment 33

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

(In reply to hansu9866 from comment #32)
> (In reply to Rachelle Yang [:ryang][[e-mail]] 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.

Comment 34

[hansu9866]

Attachment: dom_key_mapping_part1.patch

DOM Key Mapping patch
:Soft1,Soft2 and Call keys

Comment 35

[hansu9866]

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 36

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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 37

[Michael Wu [:mwu]]

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.

Comment 38

[hansu9866]

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?

Comment 39

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

> 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.

Comment 40

[hansu9866]

Attachment: dom_key_mapping_part1_v2.patch

Comment 41

[hansu9866]

(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 42

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 43

[hansu9866]

Attachment: dom_key_mapping_part_v3.patch

Comment 44

[hansu9866]

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 45

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 46

[hansu9866]

> 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;

Comment 47

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(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.

Comment 48

[hansu9866]

Attachment: DOMKeyMapping_soft1_soft2_phonecall.patch

Comment 49

[hansu9866]

> Right. Your previous patch removed those changes, but came back with current
> patch.

OK, Thank you!
I attach DOMKeyMapping_soft1_soft2_phonecall.patch

Comment 50

[Carsten Book [:Tomcat]]

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

Comment 51

[Pulsebot]

https://hg.mozilla.org/integration/b2g-inbound/rev/02a7211c3ac8

Comment 52

[hansu9866]

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?

Comment 53

[Nigel Babu [:nigelb]]

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

Comment 54

[Nigel Babu [:nigelb]]

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

Comment 55

[hansu9866]

Attachment: DomKeyMapping_and_fix_build_error.patch

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

Comment 56

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=bdb7c86fbb9c

Comment 57

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

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 58

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/integration/b2g-inbound/rev/df48164d86be

Comment 59

[hansu9866]

Attachment: patch_for_v2.2r.patch - soft1, soft2 and phonecall for v2.2r

Comment 60

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

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+.

Comment 61

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

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

Comment 62

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

(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

Comment 63

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2r/rev/4c8a5f5c566e

Comment 64

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/df48164d86be