JDK-4710498 : KeyBind Ctrl+BackSpace does not function correctly with IME
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-07-02
  • Updated: 2019-12-17
  • Resolved: 2019-12-17
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Name: dk106046			Date: 07/02/2002

java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b14)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b14, mixed mode)    

and 

java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)


Ctrl+BackSpace does not function on TextArea and TextField with IME.
The function is to put the committed phrase back to preedit.


1. Compile the following program.
------ AwtTest.java --------
import java.awt.*;
public class AwtTest extends Frame {
       public AwtTest(String msg) {
              super("TextArea");
              add(new TextArea(msg));
              setSize(300, 300);
              show();
       }
       public static void main(String[] args) {
              if (args.length < 1) {
                     new AwtTest("test message");
              } else {
                     new AwtTest(args[0]);
              }
       }
}

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

2. Execute above program
   Then the window including AWT TextArea component will come up.
3. Set focus on the window
4. Activate Japanese IM with Kanji key (ALT+Hankaku/Zenkaku)
   Then the status area on Microsoft IME change to Japanese A
5. Type any key (e.g. aa)
   Then preedit string "aa" is input in the window
6. Commit the string with pressing Enter key
   Then preedit string "aa" is committed in the window
7. Ctrl+BackSpace
   Then committed string should be put back to preedit string.
   But it is not. <--- this is problem  


Note. This test case works fine with 1.3.1
java version "1.3.1_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03)
Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode)

======================================================================

Comments
Unclear is it affecting 9 or not
19-11-2014

EVALUATION Obscene outdated low-priority bug, needs re-evaluation. Claimed FIP while no fix is really in progress, making accepted. Inessential for mustang, so decommitting.
01-09-2005

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
17-09-2004

EVALUATION What happens when the user presses Ctrl+Backspace is the following: - Windows(or IME, I am not sure) sends WM_KEYDOWN/WM_CHAR for Backspace key 'x' times, where x is the character count that is for the previously committed word. Basically this tries to erase all characters that are committed previously. - Then Windows/IME sends WM_IME_COMPOSITION message for TextField/Area to re-display the composed text. It seems that there is some regression in the AWT TextField/Area code to handle this scenario. Since the behavior for TextArea seems far more complicated than that of TextField, I'd like to explain using TextField example. The scenario: - Start a Java application which has a TextField component on Win2K Japanese. - Click on the text field to give focus to it. - Press Alt+~ to turn on the IME. - Press "a" key, then a composed text that contains Japanese HIRAGANA A appears. You can see dotted underline that represents it as a composed text. - Press "Return" key. You will notice that the composed text now gets committed (underline disappears). - Press Ctrl+Backspace key. This is supposed to retrieve the composed text (has underline with it). I tried this several times, and found that sometimes the scenario worked as expected, but sometimes not. In the problem case, when you press Ctrl+Backspace, the previously committed hiragana remained the same, and a small garbage appear (which contains a character code of DELETE), and at the end of the text there is a composed hiragana. That means that the backspace operation failed. I tried this with some Swing text components, and some sample programs of IMF active and passive clients, but none of them had the problem. This makes me think that some changes in AWT text field/area caused this regression. I am transferring this to AWT team. ###@###.### 2002-09-30 We've had a number of reports of keystrokes being processed differently (incorrectly) in TextComponents under 1.4 (see for example 4501485 and 4623376). They may all have a common cause. ###@###.### 2002-09-30
30-09-2002