JDK-8097307 : Win: [Editable ComboBox] Letter X is added to the textfield
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: fx2.1,8
  • Priority: P4
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • Submitted: 2011-11-23
  • Updated: 2015-06-12
  • Resolved: 2014-12-17
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 8
8u60Resolved
Related Reports
Relates :  
Relates :  
Description
Launch HelloComboBox application.
1. navigate to an editable ComboBox using TAB
2. press e.g. ALT-DOWN to open the active list
3. press e.g. ALT-UP to close the active list
4. release ALT

RESULT: Letter X is added to the textfield
Comments
This is no longer reproducible.
17-12-2014

Per agreement with Andrey, I assign this to Artem, who is the lead in the Glass team.
13-09-2013

We need someone with I18n experience to resolve this. Naoto, could you please suggest someone who's responsible for i18n in FX currently? IIUC, Leif doesn't have necessary expertise in this area on Windows. And neither do we (the Glass team).
13-09-2013

As stated before, this is a native problem that needs to be solved in Glass.
11-09-2013

Assigning to Naoto. The WM_CHAR messages are needed for IM processing. So someone with experience in IM should make a decision what WM_CHAR messages we could safely ignore.
16-05-2013

Assigning back to Glass team, as this is a low-level key input issue.
15-05-2013

It seems that Windows is generating a spurious WM_CHAR message after the Alt key is released. If I type a normal Shift-X, I get: WM_KEYDOWN WM_KEYDOWN WM_CHAR wParam=0x58, lParam=0x002D0001 WM_KEYUP WM_KEYUP where 58 is the code for 'X' as expected. When typing Alt-Uparrow I get: WM_SYSKEYDOWN WM_SYSKEYDOWN WM_SYSKEYUP WM_KEYUP WM_CHAR wParam=0x58, lParam=0xC0380001 Apart from the extra WM_CHAR message, it is also strange that releasing the arrow key generates a WM_SYSKEYUP, and then when releasing the ALt key I get a WM_KEYUP. This order is the same for any Alt-key combination, but only arrow keys and other non-printing keys like Home, End, PgUp, PgDown, etc, will generate the extra WM_CHAR message. I suppose I could keep state and filter this out if the WM_CHAR is not preceded by a WM_KEYDOWN, but I would feel better if I knew whether this is a system bug or part of some intended behavior. I have not found any references to this on the net, although there are some related discussions such as "What's broken in the WM_KEYDOWN-WM_CHAR input model?".
30-10-2012

Leif, would you mind taking a look at this again?
24-10-2012

Naoto: could you please take a look at the issue? I've checked and it appears that this is a native WM_CHAR event that causes this TYPED events to be generated. I know that WM_CHAR/TYPED are needed for IM code, and I recall you've developed the IM support for Glass on Windows.
24-10-2012

I disagree with postponing this to Lombard. First of all ALT-[key] is a shortcut for opening ComboBox list and shouldn't do anything else - that's a clear bug. Secondly, if it also affects other controls, as pointed out, this is no longer a medium bug, but major instead. Giving that I'm raising priority of this bug.
18-06-2012

There's certainly users who prefer to use keyboard when navigating GUI, but most users will use mouse, and this issue is not relevant in this case. Also, it doesn't crash and doesn't do anything very destructive. And this is not a regression. So yes, I believe this is of Medium priority and can be deferred to Lombard.
18-06-2012

Are you sure, this is medium and should be fixed in lombard? This is actual for TextField-like controls too, and put some strange chars after any button, pressed with ALT-modifier.
18-06-2012

Glass generates the KEY_TYPED event as a reaction to the native WM_CHAR or WM_IME_CHAR messages. Looks like we should ignore some of such CHAR events.
18-06-2012

This is more likely to be an issue in glass. Since it doesn't look like a regression, and doesn't seem serious, I might recommend pushing it to Lombard.
16-06-2012

This is reproducible in any text input control on Windows: 1. Press Alt 2. Press and release UP key 3. Release Alt When releasing Alt, a KEY_TYPED event is generated with text 'X'.
14-06-2012

Effectively reproducible in TextField and EditableComboBox on config, mentioned in previous comment, manually and with robot.
06-06-2012

Added movie about reproducibility on build 11, j2d, JDK7u6b12x32, win7.
06-06-2012

Leif, which build did you use for checking this?
06-06-2012

This is no longer reproducible in 2.2.
04-06-2012

Affected tests: ControlsAutomatedTestSuite/javafx/scene/control/test/combobox/ComboBoxTest/keyboardAltDownTest ControlsAutomatedTestSuite/javafx/scene/control/test/combobox/ComboBoxTest/keyboardAltUpTest
27-02-2012

I can recreate this in HelloTextField - it seems to be a bug in this control. Specifically, if I open HelloTextField, and press ALT, then press any one of the up/down/left/right arrows, then release ALT, I get an unexpected character in the TextField. On my machine, I get the following characters for up/down/left/right, respectively: X���,B It also seems that ALT plus other keys results in odd output too, for example ALT+Shift.
24-11-2011