WebAPI/InputMethod API with hardware keyboard

Idea

Meta bug: bug 929365.

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.

Proposed API

1. Internal API (mozInputMethod)
   1. Determine whether keyboard app is active or not
   2. Dispatch the key events to keyboard app
2. External API
   1. Register/unregister a listener to handle the key events in keyboard app
      1. mozInputMethod.inputcontext.addEventListener('keydown', function handler() {});
      2. mozInputMethod.inputcontext.removeEventListener('keydown', handler);
      3. These events are non-bubbles and cancellable
      4. The events "keydown" and "keyup" are identical to the one that the input field expects to receive
      5. 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

• Is it possible to detect the current hardware keyboard type? (e.g. qwerty or T9)