WebAPI/InputMethod API with hardware keyboard

Idea

Relevant bugs: bug 929365 (meta), bug 1110030.

The previous iteration of InputMethod API (See WebAPI/KeboardIME) enables the keyboard apps to interact with the targeted input field. We would like it to handle the connected hardware keyboard as well.

Prerequisite

The critical keys (POWER, HOME and so on) need to be handled by system app first.

Concept

This proposal is based on WebAPI/BrowserAPI/KeyboardEvent.

1. The blue lines are the current behavior. [line (1)]
2. This proposal is about adding keyboard app into the chain right before the event target (the active app).
3. In mozbrowser*before*keyXXX phase, Gecko dispatches the key events to keyboard app prior to deliver it to the event target if and only if keyboard app is active. [line (2)]
4. If keyboard app wants to handle certain keys, it should cancel the events by calling "preventDefault".
5. If keyboard app doesn't cancel the events, Gecko will then dispatch it to the event target as usual. [line (3)]
6. If keyboard app cancels the events, it should be regarded the same as cancelled by the event target and follow the same rules defined in WebAPI/BrowserAPI/KeyboardEvent.

Flowchart

Proposed API

1. Internal API (mozInputMethod)
   1. Determine whether keyboard app is active or not
   2. Dispatch the key events to mozInputMethod.inputcontext
2. External API
   1. Register/unregister a listener to handle the key events in keyboard app
      1. Add "keydown" and "keyup" events to mozInputMethod.inputcontext object
      2. Register: mozInputMethod.inputcontext.addEventListener('keydown', function handler() {});
      3. Unregister: mozInputMethod.inputcontext.removeEventListener('keydown', handler);
      4. Events are non-bubbles and cancellable.
      5. The event objects of "keydown" and "keyup" are identical to the one that the input field expects to receive
      6. No "keypress" since there's no use case

Limitation

If an input field is embedded in system app (i.e. there are only two levels: shell.html and system app) and gets the focus, we need to dispatch the events to the active keyboard app prior to system app (event target). Therefore, it will violate the prerequisite.

Short-term solution

Make the new added APIs to be certified only, and trust built-in keyboard apps doing things correctly.

Long-term solution

Moving all UIs out of the system app might be be a feasible solution.

Questions

Keyboard app may want to adapt its view or behavior based on the state of hardware keyboard. For instance, keyboard app can hide the qwerty panel and leave the candidate panel while a hardware keyboard is connected to the device.

1. How to detect whether there's a hardware keyboard connected?
2. Is it possible to detect the current hardware keyboard type? (e.g. qwerty or T9)