Bug ID: JDK-8087721 [PasswordField, InputMethods] restrict input possibilities

Type: Bug
Component: javafx
Sub-Component: controls
Affected Version: 7u6

Priority: P3
Status: Open
Resolution: Unresolved

Submitted: 2012-08-02
Updated: 2018-09-05

Other
tbdUnresolved

On macOSX, there is no any possibility to type hieroglyphs, as password. You may see, that OS switch off any language except of english, when you type is password.

In JavaFX you can type hieroglyphs in any text input control. Including passwordField. You can see, if you set up for instance chinese language, how you type english symbols, and appear popup, with candidates list (list of hieroglyphs), and starts to do conversion of english symbols to hieroglyphs.

I also talked to Naoto Sato:

Me: In JavaFX, we have PasswordField, and when you type english symbols,
they are showed as points/starts (echo symbol). (symbols are now shown).
But If I switch chinese language/keyboard layout, and start to type
symbols, popup with hieroglyphs is shown. Is that correct for password
field? 

Naoto: The bigger question is, do we want to allow input methods on
PasswordFields? Currently, we allow it, but it is sort of useless (cf.
http://javafx-jira.kenai.com/browse/RT-8986 <...>
In Swing, we don't allow input method composition and I think that is a
reasonable approach. I am not familiar with the recent FX code since
2.0, but possible approach may be to disable listening to
InputMethodEvents in PasswordField.

----------------

I checked the situation on mac. But on other OSs, the situation, I believe, the same.

SQE is ok to defer from 8u40.
18-11-2014
This seems like a good deferral candidate. I don't see this as something we can fix in 8u20.
22-05-2014
ExtendedInputMethodRequests is a private interface that may be expandable. Could we add a method there called blockIME() or such? It would return true only for PasswordField. This way we wouldn't need to add public API and disturb existing apps, at least during the 8u releases. And Scene already knows about ExtendedInputMethodRequests.
02-04-2014
My thought at that moment was to introduce a class equivalent to AWT's InputContext, where it can provide APIs that would provide those flexible input method control per node in the upcoming release.
02-04-2014
If the fix will be to disable IME only for PasswordField, and leave the rest as is, then I think we'll need some new API or property on Node for Scene to look at. Alternatively, would it be possible to create a special kind of TextInputMethodRequests subclass that marks the opposite, i.e. to disable IME? In any case, this may affect the Quantum and Glass APIs, as there would be three states: Disable IME, enable but do not forward events (current disable behavior), enable and forward (current enable behavior).
02-04-2014
Sorry I just noticed this issue, so let me put my $0.02. When I designed the input method architecture in JavaFX back in 2.0, my intention is to allow ANY nodes to be able to receive input method events. That's why all nodes are by default IME enabled, which follows the design in AWT Component. However, if you guys want to limit where to input characters with IMEs (i.e., disable IME on some nodes/controls by default), that should be fine.
02-04-2014
I ran jconsole on Windows 7 and can confirm that Swing is actively disabling IME for JPasswordField (but not for JButton). I'm wondering if we will need some new API to distinguish between the three different kinds of controls: Text input (full IME handling), PasswordField (disable IME), and others (allow IME but no specific event handling in the controls). As it is now, when RT-36495 is fixed, then IME will get disabled for all controls except text input. Can we live with that? If there are only a few other controls that need IME enabled, then maybe we can add simple inputMethodRequests handlers for them.
02-04-2014
Filed RT-36495 for Glass.
01-04-2014
The node specific code is in the Scene class, where the focusOwner invalidated() method makes calls to the peer to enable input methods, depending on whether the node has InputMethodRequests set or not. What I did was to comment out those in TextInputControlSkin, but that's not really relevant to finding the issue in Glass. Instead, take a look at how GlassView.cpp and ViewContainer.cpp use the IsInputMethodEventEnabled() method. As far as I can see it is used passively, to decide whether to handle IME events or not. I think GlassView::EnableInputMethodEvents(boolean) needs to actively enable/disable IME in Windows instead. My testing uses the Chinese (Simplified) MS Pinyin New Experience keyboard and I compared with the native controls in the Control Panel. When IME is enabled (using ctrl-space), and the focus in on native controls like buttons and password fields, the language indicator displays a circle with a slash meaning that IME is not available for those controls. This never happens with FX. We always have IME active, so the user can compose input strings even on buttons and such. A secondary question is whether we should allow IME on some controls other than for text input. MS allows it in lists, for example, where the text is used for searching rather than as input.
31-03-2014
@Leif: could you please attach a patch of what you tried and it didn't work? Note that Glass doesn't know anything about nodes, so I'm trying to figure out what exactly the code that you've changed called (or didn't call) in Glass.
31-03-2014
The class TextInputControlSkin calls setInputMethodRequests(). This should be skipped for PasswordField. I tried doing that on Windows, but it turns out that the IME is always enabled for all nodes, even when the inputMethodRequests property is null. I think this is a bug that needs to be fixed in Glass, possibly with a separate JIRA issue.
28-03-2014