C.M.Chang[:chunmin] Reporter
	Description • 9 years ago

Need to discuss a new InputMethod api to receive the keyboard events when we want to route hardware key events to keyboard app(Bug 1110030)

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 1 • 9 years ago

Please work with me on this.

I am working on bug 1137557 to route the internal call in forms.js to nsITextInputProcessor and away from nsIDOMWindowUtil which will change the API too. Ideally, it would be easier for the keyboard app simply pass the fake-or-real KeyboardEvent representing the hardware key to the new APIs to complete the flow.

	C.M.Chang[:chunmin] Reporter
	Comment 2 • 9 years ago

This bug focuses on the following points:
1. How does b2g get the status of keyboard app(active/inactive)
2. How does b2g send the hardware keyboard event to keyboard app
  a) How does EventStateManager[c++ level] forward the hardware key events to keyboard.jsm[js level]

I spent some time to organize the code flow of sending keyboard event from keyboard app to target app via b2g: http://goo.gl/4e3s6j
I hope it could be a reference to discuss(Please tell me if there is something wrong).

Actually, the suggestion from bug 1110030 comment 12 and bug 1110030 comment 24 might be a potential solution to address point 2
> we should define a "hardwareinput" object:
> mozInputMethod.inputcontext.hardwareinput.addEventListener('keydown', function handler() {});
> mozInputMethod.inputcontext.hardwareinput.removeEventListener('keydown', handler);
> to deal with some issues such as supporting multiple hardware input devices, 
> listening whether devices are connected or not, distinguishing the events' source, 
> detecting the type of devices, and so on.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 3 • 9 years ago

(In reply to Chun-Min Chang[:chunmin] from comment #2)
> This bug focuses on the following points:
> 1. How does b2g get the status of keyboard app(active/inactive)

Keyboard.jsm know that because System app will call setInputMethodActive() on the active keyboard frame.

> 2. How does b2g send the hardware keyboard event to keyboard app
>   a) How does EventStateManager[c++ level] forward the hardware key events
> to keyboard.jsm[js level]

This is probably the most important bit of this bug. I would imagine there should be some events coming from mozInputMethod.inputcontext for keyboard app to consume. Exactly what's being discussed (like you pasted below).

> 
> I spent some time to organize the code flow of sending keyboard event from
> keyboard app to target app via b2g: http://goo.gl/4e3s6j
> I hope it could be a reference to discuss(Please tell me if there is
> something wrong).
> 

This is correct.

> Actually, the suggestion from bug 1110030 comment 12 and bug 1110030 comment
> 24 might be a potential solution to address point 2
> > we should define a "hardwareinput" object:
> > mozInputMethod.inputcontext.hardwareinput.addEventListener('keydown', function handler() {});
> > mozInputMethod.inputcontext.hardwareinput.removeEventListener('keydown', handler);
> > to deal with some issues such as supporting multiple hardware input devices, 
> > listening whether devices are connected or not, distinguishing the events' source, 
> > detecting the type of devices, and so on.

	C.M.Chang[:chunmin] Reporter
	Comment 4 • 9 years ago

(In reply to Tim Guan-tin Chien [:timdream] (slow response; please ni? to queue) from comment #3)
> (In reply to Chun-Min Chang[:chunmin] from comment #2)
> > This bug focuses on the following points:
> > 1. How does b2g get the status of keyboard app(active/inactive)
> 
> Keyboard.jsm know that because System app will call setInputMethodActive()
> on the active keyboard frame.
Thx for your message, the problem now can be narrowed down to:
How does EventStateManager[c++ level] get the status of keyboard app from Keyboard.jsm?

> > I spent some time to organize the code flow of sending keyboard event from
> > keyboard app to target app via b2g: http://goo.gl/4e3s6j
> > I hope it could be a reference to discuss(Please tell me if there is
> > something wrong).
> > 
> 
> This is correct.
Thx for your check!


Summary of focus points
=================================
1. How does b2g send the hardware keyboard event to keyboard app
2. How does EventStateManager[c++ level] communicate with Keyboard.jsm[js level] mutually
   (This could be achieved by nsIObserverservice, but I think it need to define a specific 
    way to do this, like a specialized xpcom)

	C.M.Chang[:chunmin] Reporter
	Comment 5 • 9 years ago

Hi, Jayachandra,
Could you give some opinions of these issues?

	Jayachandra Yakasiri
	Comment 6 • 9 years ago

(In reply to Chun-Min Chang[:chunmin] from comment #2)
> 1. How does b2g get the status of keyboard app(active/inactive)
IMEStateManager gives us the state of IME[active/inatctive]
observerService->AddObserver(this, "ime-enabled-state-changed", true);
based on this we can find keyboard is active or not
> 2. How does b2g send the hardware keyboard event to keyboard app
>   a) How does EventStateManager[c++ level] forward the hardware key events
> to keyboard.jsm[js level]
 
1:What about adding an another path similar to below
EventStateManager::HandleCrossProcessEvent()
https://dxr.mozilla.org/mozilla-central/source/dom/events/EventStateManager.cpp#1214
2:then find the remoteBrowser for keyboard app by comparing nsGkAtoms::mozapptype,NS_LITERAL_STRING("inputmethod") from the targets[which tells that its a keyboard app or not, considering 3rd party case also]
3:then dispatch the event via tabparent to tabchild
4: use nsDOMWindowUtils to dispatch the event from tabchild to MozKeyboard.js
https://dxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp?from=nsDOMWindowUtils::SendKeyEvent&case=true#1022
5:Receive the event in MozKeyboard[handle event] and put it in _inputcontext
6:then fire a custom event _fireEvent with some eventName to keybaord app.
https://dxr.mozilla.org/mozilla-central/source/dom/inputmethod/MozKeyboard.js#578

with this approach the actual event is reconstructed in nsDOMWindowUtils and then in MozKeyboard
so sending an acknowledgement[event is consumed or not?] from keyboard app to presshell is little difficult.

	C.M.Chang[:chunmin] Reporter
	Comment 7 • 9 years ago

Hi, Masayuki, Xulei, Luke,
I wonder if I could get your inputs on this issue

	Marco Chen [:mchen]
	Comment 8 • 9 years ago

(In reply to Jayachandra Yakasiri from comment #6)
> 2:then find the remoteBrowser for keyboard app by comparing
> nsGkAtoms::mozapptype,NS_LITERAL_STRING("inputmethod") from the
> targets[which tells that its a keyboard app or not, considering 3rd party
> case also]

Target app - An app who should be the targeted frame of keyboard events is called.

In this case, the target chain will never contain the frame of keyboard app because it is not in the path between system app and target app. Then you don't have a chance to do your proposal.

>4: use nsDOMWindowUtils to dispatch the event from tabchild to MozKeyboard.js
>https://dxr.mozilla.org/mozilla-central/source/dom/base
>/nsDOMWindowUtils.cpp?from=nsDOMWindowUtils::SendKeyEvent&case=true#1022

This function will generate a keyboard event and go through the normal event path from widget.
I am not sure MozKeyboard.js can capture it or not.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 9 • 9 years ago

Sorry for the delay to reply. I'll check this early next week because I'm still not fine...

	C.M.Chang[:chunmin] Reporter
	Comment 10 • 9 years ago

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) (working slowly due to bad health condition) from comment #9)
> Sorry for the delay to reply. I'll check this early next week because I'm still not fine...
It's ok, take care! This issue is related to bug 1110030. I can summarize the discussion and the proposal to you if you need.

	Youngwoo Jo
	Comment 11 • 9 years ago

(In reply to Chun-Min Chang[:chunmin] from comment #4)
> Summary of focus points
> =================================
> 1. How does b2g send the hardware keyboard event to keyboard app
I'm Youngwoo Jo. Could I comment my opinion?

I have concern about what path should be used for transferring a hardware key event from b2g process to a content process.

The original code sends the key event via TabParent::SendRealKeyEvent and TabChild::RecvRealKeyEvent.
That's the normal case but our case is an special case for processing IME and keyboard.
If then, should we use the IPC via TabChild and TabParent?

In my opinion, we can have a dedicated path for this case such as a kind of KeyboardProxy.
It sends a keyboard event from b2g process to a content process and get back the response via MessageManager.
So the active MozInputMethod can directly receive a key event sent from KeyboardProxy.
And then the MozInputMethod generates a key event and dispatches it to the active input context.
And moreover it can handle it regardless of location of keyboard app (on b2g process or on content process)

As a result, KeyboardProxy can provide a path from EventStateManager to an active inputcontext via MessageManager.

> 2. How does EventStateManager[c++ level] communicate with Keyboard.jsm[js
> level] mutually
>    (This could be achieved by nsIObserverservice, but I think it need to
> define a specific way to do this, like a specialized xpcom)
I think KeyboardProxy can provide it if it's implemented as a JavaScript XPCOM component, because KeyboardProxy can access Keyboard.jsm.
And KeyboardProxy should be located only in b2g process and should be used as a singleton service.


Another thing is needed in this concept.
=====================================
We have to have a path from KeyboardProxy(js) to EventStateManager(c++).
The reason is that EventStateManager(c++) needs to receive the response from keyboard app via KeyboardProxy(js) and needs to run the next routines(c++).
 - Fire a mozbrowserafterkeydown event if preventDefaulted
 - Transfer a keydown event to a target app if not preventDefaulted

Is my proposal the right concept?
What do you think about this?

	C.M.Chang[:chunmin] Reporter
	Comment 12 • 9 years ago

(In reply to Youngwoo Jo from comment #11)
> (In reply to Chun-Min Chang[:chunmin] from comment #4)
> > Summary of focus points
> > =================================
> > 1. How does b2g send the hardware keyboard event to keyboard app
> I'm Youngwoo Jo. Could I comment my opinion?
> ....
> ....
Hi, Youngwoo, 
Welcome to mozilla and thank you for providing opinions! Actually, what you mention is exactly what I thought!
We may need a specialized xpcom named KeyboardProxy to forward the keyboard information between keyboard.jsm[js level] and EventStateManager[c++ level]. 

For focus point 1, how does b2g send the hardware keyboard event to keyboard app? 
Besides what you've mentioned, I think another key point is the interface of MozInputContext[1]. We can discuss more on it.

For focus point 2, How does EventStateManager[c++ level] communicate with Keyboard.jsm[js level] mutually?
Same judgement with you!
   
[1] https://dxr.mozilla.org/mozilla-central/source/dom/inputmethod/MozKeyboard.js#424
> ....
> Another thing is needed in this concept.
> =====================================
> We have to have a path from KeyboardProxy(js) to EventStateManager(c++).
> The reason is that EventStateManager(c++) needs to receive the response from
> keyboard app via KeyboardProxy(js) and needs to run the next routines(c++).
>  - Fire a mozbrowserafterkeydown event if preventDefaulted
About when to fire a keyboard event, I think we can discuss more on bug 1110030. This bug is a derivative discussion from bug 1110030 and focus on new interface to send/receive/forward the keyboard events. 

For your questions, the mozbrowserafterkey* and mozbrowserbeforekey* event will be received by the one who embed a mozbrowser iframe. Therefore, no matter Key*event.preventDefault() is called or not, the one embeddging mozbrowser iframe still can receive mozbrowserafterkeydown event. In other words, the mozbrowserafterkey* and mozbrowserbeforekey* event are independent from Key*event.preventDefault().
>  - Transfer a keydown event to a target app if not preventDefaulted
Yes, b2g should transfer a keydown event to target app if keyboard app doesn't call preventDefault().


Summary for the topic: Hardware Key Routing to IME
======================================================
- bug 1110030) Routing HW key events
  - Proposal: http://goo.gl/D5yW6c
  - Expected events order (logical sequence): http://goo.gl/wt3HiB
- bug 1161424) New API to receive keyboard event
  - How does b2g send the hardware keyboard event to keyboard app
    - How to transfer keyboard information between [c++ level] code to [js level] code?
      - We may need a specialized xpcom named KeyboardProxy(KeyboardProxy.idl)
    - May need a new MozInputContext interface like:
      - mozInputMethod.inputcontext.hardwareinput.addEventListener('keydown', function handler() {});
      - mozInputMethod.inputcontext.hardwareinput.removeEventListener('keydown', handler);
- References:
  - Keyboard events dispatch order now(bug 989198): http://goo.gl/4e3s6j
  - How keyboard app send key events to target app via b2g: http://goo.gl/4e3s6j

	Youngwoo Jo
	Comment 13 • 9 years ago

I want to propose how keyboard app identify the origin of a keyboard event.

I'm explaining the reason why it's needed, before I introduce my proposal.
==========================================================
In my opinion, keyboard app should know where the keyboard event is fired from, because keyboard app should select the proper state machine which can process the keyboard event.
If a keyboard event comes from 12 key, keyboard app should show the UI for 12key and should use the state machine to convert a keyboard event to a proper character.
e.g. In case of 12 key, the state machine converts the key code like the below.
     '2' key : 'a' ==> 'b' ==> 'c' ==> '2' ==> 'a' ==> ...
     '3' key : 'd' ==> 'e' ==> 'f' ==> '3' ==> 'd' ==> ...
However, qwerty is different with 12 key.
Qwerty keyboard event might not be converted to any other character.
That is, generally, qwerty keyboard event is expected to be used directly, without any state machine.
But, in order to support multiple language, I think qwerty keyboard should also use a state machine for mapping a key to the each language's character.
As a result, keyboard app should identify the origin of a keyboard event.

If you agree with this, I will go to the next step.
The next step is my proposal about how to transfer the origin of a keyboard event to keyboard app.

The first idea is to use |KeyboardEvent.location|.
==========================================================
Currently available predefined values are the below.
 - DOM_KEY_LOCATION_STANDARD
 - DOM_KEY_LOCATION_LEFT
 - DOM_KEY_LOCATION_RIGHT
 - DOM_KEY_LOCATION_NUMPAD
How about adding the value such as DOM_KEY_LOCATION_NUMBER, for 12 key?
However, the meaning of |KeyboardEvent.location| looks a little different with this purpose.
The values are for an indication of the location of the key on the device.
The new value, DOM_KEY_LOCATION_NUMBER, is an input device itself.
So I'm not sure whether this way is right or not.
However, I'm sure that it's a very simple solution.

The second idea is to add |type| property to hardwareinput, for identifying the keyboard event.
==========================================================
If then, keyboard app can identify the type of keyboard using |hardwareinput.type|.
e.g.
  var input = mozInputMethod.inputcontext.hardwareinput;
  switch (input.type) {
    case DOM_KEYBOARD_FULL: // The type for PC keyboard including qwerty
      input.addEventListener('keydown', qwertyHandler);
      break;
    case DOM_KEYBOARD_NUMBER: // The type for 12 key
      input.addEventListener('keydown', numberHandler);
      break;
    case XXX: // The more types are needed?
    default:
      /* Not supported */
      break;
  }

What do you guys think about this proposal?
Feel free to give me your opinion please.

And if this is not related to this bug, I will file it up as a new bug.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 14 • 9 years ago

Current purpose of KeybordEvent.location is to distinguish keys on *PC* keyboard. So, we shouldn't use (expose) it for hacky usage. The second idea sounds better to me.

	mail2tapas
	Comment 16 • 9 years ago

Please review the attached proposal and provide the input.

- Add the keyBoardType in WidgetKeyboardEvent along with keyCode,charCode [TextEvents.h]
- Add the keyBoardType in struct UserInputData along with keyCode,scanCode [nsAppShell.cpp]
- The keyBoardType of the key can be derived using the Device Classes defined in EventHub.
  [mEventHub->getDeviceClasses(deviceId) ]
  For 12Key Dial keyboard  value is 0x21[INPUT_DEVICE_CLASS_DPAD |  INPUT_DEVICE_CLASS_KEYBOARD]
  For Qwerty Keyboard value is  0x03[INPUT_DEVICE_CLASS_ALPHAKEY | INPUT_DEVICE_CLASS_KEYBOARD] 

- In nsAppShell dispatch the value of key board type through keyEventDispatcher
- In Eventstatemanager will recevice the value and  will send to mozkeyboard via keyboardappproxy
- The same can be received in inputmethod.
- Based on the device_type the mozInputMethod.inputcontext.hardwareinput can be updated [NUMBER or QWERY]
- Based on hardwareinput type the corresponding handler to be invoked in Keyboard App

Need to analyze the complexity of adding keyBoardType along with keyCode and charCode in WidgetKeyboardEvent

	Marco Chen [:mchen]
	Comment 17 • 9 years ago

(In reply to Youngwoo Jo from comment #13)

May I double confirm your use case?

1. There might be more then one IME types in the keyboard app. ex: T9 and others for each languages.
2. There might be more then one hardware keyboard types. ex: 12 keys of feature phone or qwerty keyboard
3. Keyboard app would like to know what kind of keyboard type this event came from then deciding to use a certain IME type (T9 or others).

Is this right?

---------------------

Based on my assumption, I don't feel we need this new property of keyboardType.
Because in FxOS now, the IME types doesn't be auto-changed regarding to the key came from what type of keyboard. That said, T9 state machine will be performed no matter what keyboard events are coming once user made to decision of using T9 IME (for alphabet keys, just post it to input field.).

If a phone equipped with 12 keys and query keyboard then I don't feel the IME should be changed continuously just because user stroke keys from both of 12keys and qwerty keyboards

	Youngwoo Jo
	Comment 18 • 9 years ago

First of all, I'm late to give my thanks to you but I appreciate your comment, Masayuki.

(In reply to Marco Chen [:mchen] from comment #17)
> (In reply to Youngwoo Jo from comment #13)
> 
> May I double confirm your use case?
> ...
> Is this right?
Yes, that's right.

> Based on my assumption, I don't feel we need this new property of
> keyboardType.
> Because in FxOS now, the IME types doesn't be auto-changed regarding to the
> key came from what type of keyboard. That said, T9 state machine will be
> performed no matter what keyboard events are coming once user made to
> decision of using T9 IME (for alphabet keys, just post it to input field.).
In my opinion, I think IME should be auto-changed regarding to the key for more usecases and for better UX.
However, as you know, currently not yet auto-changing supported.
If we provide the info to keyboard app, auto-changing can be provided to the users.

> If a phone equipped with 12 keys and query keyboard then I don't feel the
> IME should be changed continuously just because user stroke keys from both
> of 12keys and qwerty keyboards
If then, do you mean it's possible to handle the keys from both of 12keys and qwerty keyboards in the same way?
If that's right, I don't agree with you because qwerty and 12keys can not be handled in the same way.
They should have their own state machines.
e.g.
'2' from qwerty => just '2'
'2' from 12keys => 'a'

If I don't understand your thoughts correctly, let me know please.

	Marco Chen [:mchen]
	Comment 19 • 9 years ago

(In reply to Youngwoo Jo from comment #18)
> In my opinion, I think IME should be auto-changed regarding to the key for
> more usecases and for better UX.
> However, as you know, currently not yet auto-changing supported.
> If we provide the info to keyboard app, auto-changing can be provided to the
> users.

This might be a great feature and you need UX input or product requirement to secure this.
Since this requirement becomes an improvement, the new bug can be fired to do more discussion.
And let us keep the topic here of whether we need a NEW API in MozInputMethod interface for retrieving the keyboard events. 
 
> If then, do you mean it's possible to handle the keys from both of 12keys
> ...
> If I don't understand your thoughts correctly, let me know please.

The same comment as above.

	Youngwoo Jo
	Comment 20 • 9 years ago

I filed a new bug, Bug 1181414, for the further discussion about auto changing IME.

	C.M.Chang[:chunmin] Reporter
	Comment 21 • 9 years ago

(In reply to Youngwoo Jo from comment #18)
> > Based on my assumption, I don't feel we need this new property of
> > keyboardType.
> > Because in FxOS now, the IME types doesn't be auto-changed regarding to the
> > key came from what type of keyboard. That said, T9 state machine will be
> > performed no matter what keyboard events are coming once user made to
> > decision of using T9 IME (for alphabet keys, just post it to input field.).
> In my opinion, I think IME should be auto-changed regarding to the key for
> more usecases and for better UX.
> However, as you know, currently not yet auto-changing supported.
> If we provide the info to keyboard app, auto-changing can be provided to the
> users.
> 
> > If a phone equipped with 12 keys and query keyboard then I don't feel the
> > IME should be changed continuously just because user stroke keys from both
> > of 12keys and qwerty keyboards
> If then, do you mean it's possible to handle the keys from both of 12keys
> and qwerty keyboards in the same way?
> If that's right, I don't agree with you because qwerty and 12keys can not be
> handled in the same way.
> They should have their own state machines.
> e.g.
> '2' from qwerty => just '2'
> '2' from 12keys => 'a'
> 
> If I don't understand your thoughts correctly, let me know please.
Hi, Youngwoo,
I need to understand the usecase first. 
1)Is the device equipped with a 12keys keyboard and qwerty keyboard at the same time? 
2)does the device has a touch screen that can show 12keys keyboard layout or qwerty keyboard layout?

	Youngwoo Jo
	Comment 22 • 9 years ago

(In reply to Chun-Min Chang[:chunmin] from comment #21)
> Hi, Youngwoo,
> I need to understand the usecase first. 
> 1)Is the device equipped with a 12keys keyboard and qwerty keyboard at the
> same time? 
> 2)does the device has a touch screen that can show 12keys keyboard layout or
> qwerty keyboard layout?
This requirement is not only for red-tai, just for the future usecases.
So I have no choice but to reply on the base of the general feature phones.
About 1), yes, there are several commercial feature phones equipped with both of them.
About 2), no, we can not assume that all devices have a touch screen.

One usecase is the following.
Let's assume a basic phone has a built-in 12key and it has HID bluetooth keyboard feature.
Bluetooth qwerty keyboard or 12key keyboard can be connected to the phone.
And let's assume a qwerty connected to the phone via bluetooth.
At this time, keyboard app can receive a keyboard event from both of them.
And keyboard app should know the type of keyboard because of the reason commented previously.

How about this usecase?

	C.M.Chang[:chunmin] Reporter
	Comment 23 • 9 years ago

(In reply to Youngwoo Jo from comment #22)
> This requirement is not only for red-tai, just for the future usecases.
> So I have no choice but to reply on the base of the general feature phones.
> About 1), yes, there are several commercial feature phones equipped with
> both of them.
> About 2), no, we can not assume that all devices have a touch screen.
> 
> One usecase is the following.
> Let's assume a basic phone has a built-in 12key and it has HID bluetooth
> keyboard feature.
> Bluetooth qwerty keyboard or 12key keyboard can be connected to the phone.
> And let's assume a qwerty connected to the phone via bluetooth.
> At this time, keyboard app can receive a keyboard event from both of them.
> And keyboard app should know the type of keyboard because of the reason
> commented previously.
> 
> How about this usecase?
If there are commercial considerations and the feature phone indeed has this requirement, this feature is ok to me. 

In my opinion, the only difference of auto-changed IME and the original IME(non-auto-changed) is "one click". In fact, most users whose official language isn't English have multiple IMEs. In Taiwan, most users have Chinese input method and English input method. In Japan, most users have Japanese input method beside English input method. (Although Chinese input method and Japanese input method might have similar keyboard layout as English input method, I think the ways to handle the keys are totally different.) Now, if users want to switch the input methods, they need to click a software button shown on keyboard app by themselves. For me, auto-changed IME will be convenient when I have to use two different (hardware) keyboard at the same time because I don't need to click the switch button by myself.

	Jayachandra Yakasiri
	Comment 24 • 9 years ago

Hi,
Here I am attaching basic hardwareinput Interface patch,
this patch is dependent on 
https://bugzilla.mozilla.org/attachment.cgi?id=8654730
with this patch keyboard application can listen events by adding addEventListeners to hardwareinput
ex:[mozInputMethod.inputcontext.hardwareinput.addEventListener('keydown', function handler() {});]
please let us know your comments on the patch.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 25 • 9 years ago

WebIDL will have to be rebased on top of bug 1197700 when landing. Sorry about that.

	C.M.Chang[:chunmin] Reporter
	Comment 26 • 9 years ago

Comment on attachment 8654751 [details] [diff] [review]
IME_Basic_hardwareinput_interface.patch

I think Tim would be a better choice to review this patch. He is familiar with this staff.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 27 • 9 years ago

Comment on attachment 8654751 [details] [diff] [review]
IME_Basic_hardwareinput_interface.patch

It sounds like that keyboard apps need to listen hardware keyboard events by themselves. That means that keyboard apps *can* do not support hardware keyboard. It's bad scenario when we allow to install third party's keyboard apps. But I don't have better idea. So, this must be good approach.

	C.M.Chang[:chunmin] Reporter
	Comment 28 • 8 years ago

This is already implemented in bug 1110030