forms.js requirements

About

This document is a draft and an attempt to reconcile between the mash currently in forms.js and the newly implemented, D3E-aware nsITextInputProcessor. The outcome of this document is to find out the requirements of the current implementation and what are the new C-based interface it should rely on, instead of legacy nsIDOMWindowUtils.

Ideally we should document not only the current implementation, but also the requirements to make this fully D3E compatible.

The related work is bug 1137557.

What is forms.js

forms.js is the remote end of the Input Method API, responsible of handling input fields for the active API user (the keyboard app).

It is loaded by browser-element exactly once on every content/chrome process, on the topmost widget.

Requirements

Focus management

1. Send an async message when any of the text inputs (input/textarea/contenteditable) receives focus
2. Send an async message when any of the select receives focus
3. Send an async message when any of the text inputs (input/textarea/contenteditable) lost focus
4. Send an async message when any of the select lost focus

Focus are currently detected by listen to DOM events L193. Valid elements are currently filter in JS logic L362-L391.

Blur can happen not only the real blur (detected by DOM event L194) but also removal from DOM tree (detected by mutation observer L298.

Issues

1. Can we use nsITextInputProcessor to detect focus instead? Select elements however should be handled separately.
2. Would it be possible even moving this global focused element detection to the chrome process, not forms.js in every process? We had some async message ordering issue before, see Keyboard.jsm#L286.

Input handling

Text input

Select