WebAPI/InputMethod API with hardware keyboard: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 34: Line 34:
== Limitation ==
== 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 prior to system app (event target). Therefore, it will violate the prerequisite.
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'''
'''Short-term solution'''


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


''' Long-term solution'''
''' Long-term solution'''


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


== Questions ==
== Questions ==


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

Revision as of 07:29, 24 December 2014

Meta bug: bug 929365.

Idea

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.

Proposal

InputMethod API with hardware keyboard Concept.jpg

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.

TBD

  1. Internal API
    1. How to determine whether keyboard app is active or not?
    2. How to dispatch the key events to keyboard app
  2. External API
    1. How to register/unregister a listener to handle the key events in keyboard app? (inputContext.addEventListener() ?)
    2. How many categories of the events are needed? (keydown and keyup should be required. How about keypress?)
    3. What is the event name? (keyXXX or mozbrowserbeforekeyXXX may be not appropriate since keyboard app is never focued)

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)
Retrieved from "https://wiki.mozilla.org/index.php?title=WebAPI/InputMethod_API_with_hardware_keyboard&oldid=1043917"