Java Solaris Communities Sun Store Join SDN My Profile Why Join?
» search tips 
Sun Developer Network
Developers Home > Products & Technologies > Java Technology > Community > Bug Database >
Join SDNWhy Join
 
Bug Database
Bug Detail
Quick Lists
-  Top 25 Bugs
-  Top 25 RFE's
-  Recently Closed Bugs
Printable Page Printable Page


Bug Database
Welcome
 
»  Login
»  Report a Bug
»  FAQs
  Bug Watch List:
» Watch this Bug
 Bug Votes:
» Vote for this Bug
Bug ID: 6506617
Votes 58
Synopsis Keyboard-lock in swing program on Linux box
Category java:classes_awt
Reported Against
Release Fixed
State 5-Cause Known, bug
Priority: 2-High
Related Bugs 6299259
Submit Date 20-DEC-2006
Description 
FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
RHEL 4 - Linux 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux
Red Flag 5 - Linux 2.6.9-11.19AXsmp #1 SMP Fri Aug 5 05:28:32 EDT 2005 i686 i686 i386 GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
gnome-desktop-2.8.0-5
kdebase-3.2.1-62AX.i386.  kdelibs-3.2.1-44AX.i386.


A DESCRIPTION OF THE PROBLEM :
Run some swing program, keyboard is locked after some opterations, then it don't respond any key event.

Here is a demo program, no multi-thread, no event-dispatching thread problem. It always can be reproduced on RHEL 4 and Red Flag 5.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the program I post, follow the steps in "about":

1 - press Alt+N to navigate next, and don't release keys untill there are no more next page, then try Alt+B to navigate back and also don't release keys untill page 0, repeat Alt+N and Alt+B again and again, keyboard will be locked during navigating.

2 - press Alt+A in main window, it will popup an about dialog, then press down space key and don't release, the about dialog will be closed and opened again and again, keyboard will be locked sooner or later.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Keyboard should not be locked!

ACTUAL -
The keyboard focus is there, but it don't respond any key event in all component and window, except in JPasswordField.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package test;

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import java.util.*;

public class KeyLock extends JFrame {
  JPanel contentPanel = new JPanel();
  JPanel wizardToolPan = new JPanel();
  JButton btnBack = new JButton("Back");
  JButton btnNext = new JButton("Next");
  JButton btnAbout = new JButton("About");
  public static final String aboutMsg =
          "<html>  This program will help to find keyboard lock problems, two way to reproduce:<br><br>" +
          "1 - press Alt+N to navigate next, and don't release keys untill there are no more next page, <br>" +
          "then try Alt+B to navigate back and also don't release keys untill page 0,<br>" +
          "repeat Alt+N and Alt+B again and again, keyboard will be locked during navigating. <br><br>" +
          "2 - press Alt+A in main window, it will popup an about dialog,<br>" +
          "then press down space key and don't release, <br>" +
          "the about dialog will be closed and opened again and again,<br>" +
          "keyboard will be locked sooner or later." +
          "</html>";

  public KeyLock() {
    this.setDefaultCloseOperation(EXIT_ON_CLOSE);
    this.setTitle("Keyboard lock test");

    getContentPane().setLayout(new BorderLayout());
    btnBack.setMnemonic('B');
    btnBack.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent e) {
        KeyLock.this.goBack(e);
      }
    });

    btnNext.setMnemonic('N');
    btnNext.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent e) {
        KeyLock.this.goNext(e);
      }
    });

    btnAbout.setMnemonic('A');
    btnAbout.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent e) {
        JOptionPane.showMessageDialog(KeyLock.this, aboutMsg, "About", JOptionPane.INFORMATION_MESSAGE);
      }
    });

    contentPanel.setLayout(new BorderLayout());
    contentPanel.setPreferredSize(new Dimension(400, 250));
    contentPanel.setMinimumSize(new Dimension(400, 250));

    wizardToolPan.setLayout(new FlowLayout());
    wizardToolPan.add(btnBack);
    wizardToolPan.add(btnNext);
    wizardToolPan.add(btnAbout);

    this.getContentPane().add(contentPanel, java.awt.BorderLayout.CENTER);
    this.getContentPane().add(wizardToolPan, java.awt.BorderLayout.SOUTH);

    this.setSize(400, 300);
    this.createContentPanels();
    this.showCurrent();
  }

  private Vector<JPanel> slides = new Vector<JPanel>();
  private int current = 0;

  private void createContentPanels() {
    for (int j = 0; j < 20; ++j) {
      JPanel p = new JPanel(new FlowLayout());
      p.add(new JLabel("Page: " + j));
      p.add(new JTextField("Page: " + j + ", input something here", 20));
      p.add(new JTextField("Page: " + j + ", input something here", 20));
      p.add(new JTextField("Page: " + j + ", input something here", 20));
      p.add(new JLabel("Input something in password box:"));
      p.add(new JPasswordField(20));
      p.add(new JCheckBox("Try click here, focus will be here."));
      p.add(new JRadioButton("Try click here, focus will be here."));

      slides.add(p);
    }
  }

  public void showCurrent() {
    if (current < 0 || current >= slides.size())
      return;

    JPanel p = slides.get(current);
    this.contentPanel.add(p, java.awt.BorderLayout.CENTER);
    this.pack();

    Component[] comps = p.getComponents();
    if (comps.length > 0) {
      comps[0].requestFocus(); // try delete this line
    }
    this.repaint();
  }

  public void goNext(ActionEvent e) {
    if (current + 1 >= slides.size())
      return;
    this.contentPanel.remove(slides.get(current));
    current++;
    sleep(100);
    this.showCurrent();
  }

  public void goBack(ActionEvent e) {
    if (current <= 0)
      return;
    this.contentPanel.remove(slides.get(current));
    current--;
    sleep(100);
    this.showCurrent();
  }

  public static void sleep(int millis) {
    try {
      Thread.sleep(millis);
    } catch (Exception e) {
      e.printStackTrace();
    }
  }

  public static void main(String[] args) {
    KeyLock wizard = new KeyLock();
    wizard.setVisible(true);
  }
}

---------- END SOURCE ----------
Posted Date : 2006-12-20 13:20:13.0
Work Around 
When the keybord lock occurs, the user can navigate with mouse click although this is not very accessible workaround.
Evaluation 
Using RHEL4 with ja_JP.UTF-8 locale, KeyPress events were consumed by XFilterEvent when it's running with XToolkit (default); however, this is not a case with MToolkit.

While XToolkit passes window argument when it calls XFilterEvent, MToolkit passes NULL. When NULL is passed, keylock problem does not happen. However if NULL is passe in XToolkit, input method gets disabled.
Posted Date : 2007-03-14 23:19:40.0

The issue is seen in XToolkit.
JDK5 and later versions all have the same problem. 
Currently, targeted to 7, then we'll plan to backport.
Posted Date : 2007-03-14 23:21:56.0

(tested on Solaris 10 sparc)
I don't believe this is an input method issue, but rather AWT focus or dialog modality issue.  Here are the reasonings for it:

- I could reproduce the problem even if I pass 0 (NULL) for XFilterEvent() for the second issue.
- When I try to reproduce the second issue (modal dialog open/close one), some space keys are actually dispatched to the shell window that started the test case, which means that modality is broken.  Also, when the lock happens, I see a couple of the "About" dialogs shown at the same time.
- It's harder to reproduce the problem in 'C' locale, however, if you run a lot of applications at the same time (e.g., running 5 instances of Java2Demo), I could reproduce it in 'C'.  So I believe this is locale/inputmethod independent.


Transferring to the AWT.
Posted Date : 2007-08-10 00:03:20.0

This may be a platform issue (cf. http://bugs.freedesktop.org/show_bug.cgi?id=7869).  The description in the 'comment' section is very similar the investigation on freedesktop.org one.
Posted Date : 2007-08-14 20:13:08.0
Comments
  
  Include a link with my name & email   

Submitted On 18-JAN-2007 
I found if we disable input method with enableInputMethods(false) , the component will respond key event when lock occur, just like JPasswordField does. But we need input method in our program.
Is there any other way to workaround? Please give me some suggestion, thanks!


Submitted On 23-JAN-2007 
this problem is really troublesome


Submitted On 26-JAN-2007 
If you can't reproduce it, try to switch language of your Linux desktop to Simplified Chinese, and run the test program again.


Submitted On 06-FEB-2007 
I have experieneced something similar while running with JEdit and Netbeans where I'll switch to a different program then switch back and then can not enter in anything into the text editors for either program.  The workaround I've been using it to find any text area or JTable where I can select and enter in text, then I'll cancel what I was doing and things seem to reset back so I can use the text editors (until it happens again).


Submitted On 21-FEB-2007 
Noticed that this also happens on FC6 and in desktop applications. Killing all SCIM processes fixes the problem. bug 6299259 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6299259) seems to be the same problem.


Submitted On 24-FEB-2007 
seems this is one bug of libx11.
http://lists.debian.org/debian-x/2006/12/msg00699.html
http://bugs.winehq.org/show_bug.cgi?id=6547


Submitted On 28-FEB-2007 
I encounter this problem too. wish it will be fix soon.


Submitted On 01-MAR-2007 
it seems that SUN Java got some threading problem.

 i traced the program above using gdb, one thread calls XCreateIC to create Input Context for the "OK" button of the pop'd up dialog: 

(gdb) thread
[Current thread is 2 (Thread -1480590416 (LWP 23959))]
#0  0xa7f7034e in XCreateIC () from /usr/X11R6/lib/libX11.so.6
#1  0xa8638a98 in Java_sun_awt_X11GraphicsEnvironment_getXineramaCenterPoint
()
   from /usr/java/jdk1.5.0_04/jre/lib/i386/xawt/libmawt.so
#2  0xa8639349 in Java_sun_awt_X11_XInputMethod_createXICNative ()
   from /usr/java/jdk1.5.0_04/jre/lib/i386/xawt/libmawt.so
#3  0xb290243b in ?? ()
#4  0xa806a96c in ?? ()
#5  0xa7af42ec in ?? ()
#6  0x01400031 in ?? ()
#7  0x00000000 in ?? ()

while another thread is sitting there to process the incoming XEvent:

(gdb) thread
[Current thread is 4 (Thread -1475978320 (LWP 23957))]
#0  0xa81eef5a in XFilterEvent () from /usr/X11R6/lib/libX11.so.6
#1  0xa82a736a in Java_sun_awt_X11_XlibWrapper_XFilterEvent ()
   from /usr/java/jdk1.5.0_04/jre/lib/i386/xawt/libmawt.so
#2  0xb290243b in ?? ()
#3  0x0828c96c in ?? ()
#4  0xa8064e8c in ?? ()
#5  0x08233470 in ?? ()
#6  0x00000000 in ?? ()

libX11 is not thread-safe, which means you cannot call most libX11 library function in different thread.

here is what happened, under normal condition, if user press the keyboard, following actions will be taken step by step:

  1. keylock program take XEvent from the event queue, then call XFilterEvent() to progress the incoming key events, then send XIM_FORWARD_EVENT to XIM Server (e.g. SCIM) for it to decide whether to handle it or not.
  2. if SCIM is in English mode, then it will send the event back to keylock by sending XIM_FORWARD_EVENT back, then sitting there wait until keylock returns XIM_SYNC_REPLY (this is the behavior of the default synchoronous input mode), if some new key events is forwarded later, SCIM will simply queue them until XIM_SYNC_REPLY is received.
  3. keylock get the keyboard XIM_FORWARD_EVENT  event sent back by SCIM, it knows SCIM wants it to handle that itself, so the corresponding IC (Input Context) will be set as FABRICATED (misspelled as FABLICATED in libX11), and it's also marked as MARK_NEED_SYNC_REPLY since the real key event is not processed yet, so it cannot return SYNC_REPLY to SCIM yet. in the end, a new key event is created and put back on the _head_ of event queue.
  4. the key event put back in step 3 is accepted in the next call of XFilterEvent(), since the IC is already in the FABRICATED mode, it will send MARK_NEED_SYNC_REPLY to SCIM so that SCIM will be released to process its event queue (not X Event queue).

OK, if this is not confusing enough, here is what happened if a second thread sneaking in:

imagine after step 3, another thread is waken up to create some new IC (like the "OK" button of pop'd up dialog). the newly created IC will register itself a new handler for the XIM events, which will "steal" the key event created by step3. so in step 4, the new IC will take over to process that key event, however since it is not marked as FABRICATED, it will not send MARK_NEED_SYNC_REPLY to SCIM, it will just forward the key event to SCIM instead. while SCIM is sadly sitting there waiting for SYNC_REPLY that will never comes, and the new IC is miserably sitting there waiting for FORWARD_EVENT that never comes. so the keyboard seems dead.

I tried IBM java 1.5.0 (a.k.a IBM Java 2 v5.0), it does not suffer such kind of problem. so it seems to be SUN Java specific bug.

this problem can be workaround by turning off the synchronous mode of XIM, though there must be some kind of side-effect that I don't know.


Submitted On 16-MAR-2007 
yes,I 'm crazy with my JEdit with this bug


Submitted On 26-MAR-2007 
How to turn off the synchronous mode of XIM?


Submitted On 05-APR-2007 
Has any progress been made on this problem?  Is there a workaround?


Submitted On 21-APR-2007 
I WANT THIS BUG TO BE FIXED!!!!


Submitted On 21-APR-2007 
This bug didn't occur in opensolaris b61 when running in CDE 1.7 on a Xsun Xserver.


Submitted On 21-APR-2007 
BEA Jrockit JDK6 also has this bug....
good new to you guys....but news to our linux user....
there's only one JVM that i didn't try...
IBM JDK...


Submitted On 13-JUN-2007 
This bugs appears under Ubuntu and the jdk6 included in its repositories (version 6-00-2ubuntu2 ) 1.6.0-b105.
However, the jdk5 (also, the one included in its repositories) doesn't have this bug.
I hope it get's fixed soon, because using jdk5 means a poor GTK L&F for linux users


Submitted On 14-AUG-2007
kmwang 
>>This may be a platform issue (cf. >>http://bugs.freedesktop.org/show_bug.cgi?id=7869).  The description in the >>'comment' section is very similar the investigation on freedesktop.org one.
>>Posted Date : 2007-08-14 20:13:08.0
http://bugs.freedesktop.org/show_bug.cgi?id=7869 seems not the reason.
see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6568693, this is very seem to this bug.


Submitted On 06-DEC-2007
paul.x 
I'm a Java developer. I would like to use features of modern IDEs like IntelliJ IDEA or NetBeans. However, currently I'm forced to use Eclipse. Is any progress on this bug??


Submitted On 18-DEC-2007 
I am having this issue on Ubuntu 7.10 and it is driving me crazy!! Please fix this issue, and I will be greatly appreciated!!


Submitted On 11-JAN-2008
paulie.x 
It seems that java maintainers have a lot of work on other major issues, probably something like support of new native look in windows vista.

This is HANDICAP !!!


Submitted On 20-JAN-2008
v.tst 
this bug doesn't happen if you disable your compiz. but still it should be somehow fixed.


Submitted On 20-JAN-2008
paulie.x 
v.tst : who told you i'm using compiz
yes, it happens without compiz!


Submitted On 25-JAN-2008
v.tst 
in my case without compiz it doesn't happen, so it is just my observation...


Submitted On 25-JAN-2008
JonesLeon 
Why can not fix it over a year!


Submitted On 27-JAN-2008
paul.x 
Hello, maybe I found some "solution", but I really don't know what I'm doing and I haven't tested it more deeply yet.

Here is the procedure that caused keyboard lock in NetBeans 6.0.

1. Go to netbeans installation directory
2. $ bin/netbeans
3. Try to move in editor with cursor keys (it should work)
4. Press Ctrl-Shift-O, "Open Project" dialog appears, press escape to return

Now I cannot use the keyboard.

So I tried:
$ export AWT_TOOLKIT=XToolkit
and repeated above procedure. The keyboard responded :D.

Then I tried:
$ export AWT_TOOLKIT=MToolkit
and repeated above procedure. Keyboard lock occured again.

I have Ubuntu 7.10, Java JRE 1.6.0_03 and I also uninstalled all scim packages.


Submitted On 27-JAN-2008
paul.x 
DAMN!
I found
AWT_TOOLKIT=MToolkit
in /etc/enviroment

When I first tried Compiz I had some problems with Java apps, so in some forum I found that setting this variable will solve it.

So I deleted it and it's ok so far.


Submitted On 29-JAN-2008
v.tst 
oh, great  :)
as i remember i set the variable
AWT_TOOLKIT=MToolkit
in order to conciliate compiz and swing applications... so, now it works without and no problems with locking.
thnks


Submitted On 12-FEB-2008
IanLewis 
Setting AWT_TOOLKIT=MToolkit does not seem to work. It actually seems to be worse. It is reproduceable by closing a window with escape.

Setting AWT_TOOLKIT=XToolkit seems to make it a little less severe but it still happens when window switching.


Submitted On 06-JAN-2009
bwagnermpower 
Our company was harmed by this bug today.  Why isn't this critical issue being addressed?  This problem involves a core service layer and has been open for over 2 years.  We had the same symptoms; Swing ceases receiving key events on our RHEL server.  This broke a critical admin utility for which we had to work around.  I found this bug ID, compiled the example given in the bug description, and was able to reproduce the exact same symptoms that we experienced (key events no longer received by Swing).  We know it is the same issue because it breaks all key events, including the directional keys that interact with our JTables, for example.  Since this involves AWT for a specific JRE distribution, PLEASE elevate the priority of this bug.  Our server specs:  

Red Hat Enterprise Linux Server release 5.2 (Tikanga) 
Linux 2.6.18-92.1.6.el5 #1 SMP Fri Jun 20 02:36:06 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux 
Gnome 2.16.0 

java version "1.6.0_11" 
Java(TM) SE Runtime Environment (build 1.6.0_11-b03) 
Java HotSpot(TM) 64-Bit Server VM (build 11.0-b16, mixed mode)


Submitted On 19-JAN-2009
vj_roba 
How long does it take to fix this bug!?
It made my software useless on Linux.
I really want it to be fixed.


Submitted On 19-JAN-2009
vj_roba 
I hope people in Sun understand that this bug makes all Swing/AWT applications useless on Linux in non English country.


Submitted On 04-JUN-2009
alepe.com 
I uninstalled scim and installed uim and the problem gone so far.


Submitted On 05-SEP-2009
Tri.Bao 
I found a workaround:

Assume on the form, you have a JPasswordField and a button (a form must have at least one button :-) ). Then add a FocusLister into the JPasswordField field. In the focusGained, do the following:

- Fire a mouse_PRESS (press, not click) event to the button
- request the focus back to the JPasswordFied
(of course, we have to make sure no infinity calls to the focusGained, just simply use a boolean flag)



PLEASE NOTE: JDK6 is formerly known as Project Mustang





About Sun  |  About This Site  |  Newsletters  |  Contact Us  |  Employment
How to Buy  |  Licensing  |  Terms of Use  |  Privacy  |  Trademarks
 

 
Copyright 1994-2008 Sun Microsystems, Inc.
A Sun Developer Network Site

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.
 
XML Content Feeds