JDK-8102248 : Virtual Keyboard: Input Method Constraints
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 7u6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2012-02-02
  • Updated: 2015-06-16
  • Resolved: 2012-05-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7u6Fixed
Related Reports
Relates :  
JDK-8097928 - Add Formatted TextField control
Description
From A360:
Applications must be able to specify that a text field accepts a certain class of input (e.g. e-mail, phone number, URL, plain text). A virtual keyboard, if present, should adjust its presented set of characters to the input class. Input method constraints are hints: an implementation is not required to restrict the set of characters that can be entered. (API requirement on FX, implementation requirement on convergence).

Update:
This requirement must also include constraints of scripts (e.g., katakana) so that only input of a single script are accepted.

Controls team update:
The Input Method Constraints support is a intended to be used by developers as a means to provide a hint to keyboards (particularly virtualised keyboards) such that they may customise what is displayed to the user. For example, if a TextField is intended to be used for accepting a phone number, an input method constraint may be set on it to state this intention. When a virtualised keyboard is shown for this field, it may change from alphanumeric to being simply a number pad.

The UI Controls team met on February 2, and discussed this and what we believe the requirements are. The discussion centered around the following points:

 * There is concern about how this may relate to the formatted text requirement (RT-14000), and this needs to be explored further.
 * Very basic on the desktop.

Based on the UI controls team discussion, the 'planning poker' value for this feature was deemed to be 3.
Comments
There will only be internal, undocumented support in 2.2. An application can set a node property on the text input control with the key "vkType" and a String value which is one of: "Text", "Numeric", "URL", or "Email". If not specified, the type defaults to "Text". Example: textField.getProperties().put("vkType", "URL");
10-05-2012
when can SQE expect first drop for testing?
10-05-2012
We need to decide whether the new property either: a) sets a content type on the text input controls, with documentation stating that the current implementation only uses this for choosing a virtual keyboard type on embedded systems, and does not yet restrict input from physical keyboards. "contentType(enum)" or b) directly sets a desired virtual keyboard type for embedded systems. "virtualKeyboardType(enum)"
02-05-2012
The implementation for 2.2 will only support limiting the type of input on a virtual keyboard to either Text, Numeric, URL, or Email address. It will not restrict input from a physical keyboard and will have no impact on desktop input methods.
02-04-2012
Can you please provide the specification for API and input formats? We would like to understand how the input constraints will be set and defined for controls Which controls will be affected?
10-02-2012
Could you please confirm that controls will not restrict input but will only have some API that describes input constraints. These constraints are therefore only 'for information only' and are not enforced by control.
10-02-2012
Increasing priority to match corresponding A360 item.
08-02-2012
Implements A360 Feature http://oracleplan.oracle.com/gotoEntity?entityType=FEATURE&entityId=717600&version=0
02-02-2012