JDK-4214799 : Solaris: Component focus is lost when using menu
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.2.0,1.2.2,1.3.1
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS:
    solaris,solaris_2.5.1,solaris_2.6,solaris_8 solaris,solaris_2.5.1,solaris_2.6,solaris_8
  • CPU: generic,x86,sparc
  • Submitted: 1999-02-25
  • Updated: 2002-07-31
  • Resolved: 2002-07-26
Related Reports
Duplicate :  
JDK-4250396 - InputMethod turned off when menu was opened
Duplicate :  
JDK-4391718 - Ladybird:Input method switching does not work well Solaris sparc and x86
Duplicate :  
JDK-4395823 - Regression: Another IM can't be actived in ladybird b11
Duplicate :  
JDK-4238981 - Focus not return to the previous components after menu clicked( mixed test. )
Relates :  
JDK-4124119 - lightweight component lost the focus after draging the frame by mouse
Relates :  
JDK-4204543 - Composed text not committed when switching input method from menu
Relates :  
JDK-4241538 - Regression: Wrong isTemporary() status of FocusLost event on Solaris
Relates :  
JDK-4163339 - Arrow Keys does not work in most of the SMC dialogs; input methods disabled
Relates :  
JDK-4124969 - Wrong status in FocusOut event when open system menu.
Description
Run test/java/awt/im/IMFDemo on Solaris. Click into one of the lightweight components so it gets the focus and shows a thick outline. Pull down the system menu from the upper left corner of the window. Notice that the component loses its outline, indicating it has lost its focus. If you have the Kestrel version of IMFDemo, which has a menu bar with Locale and Size menus, try the same with those menus. Whenever you use a menu, the components lose focus.

This is a highly annoying user interface problem, and in addition also impacts the input method framework, which relies on focus to correctly associate components with input contexts and input methods.
Comments
EVALUATION See Comments. norbert.lindenberg@Eng 1999-02-24 The behavior has changed in Cricket-H: but it's still not quite right. Now, if I use the system menu, the component regains the focus after the menu goes away. If I use a menu from the menu bar, the focus jumps to the bottom component after the menu goes away. While the menu is up, the focus is still lost. norbert.lindenberg@Eng 1999-02-24 Here is a reduced test case for this bug... import java.awt.*; import javax.swing.*; public class test extends JPanel { JTextArea lwTextArea = new JTextArea(); TextArea hwTextArea = new TextArea(); public test() { setLayout(new GridLayout(2,1)); add(lwTextArea); add(hwTextArea); } public static void main(String [] argv) { JFrame frame = new JFrame(); MenuBar menuBar = new MenuBar(); frame.setMenuBar(menuBar); frame.setSize(new Dimension(200,200)); frame.getContentPane().setLayout(new BorderLayout()); frame.getContentPane().add(new test()); frame.setVisible(true); } } Steps to reproduce... 1) Click in the top textarea to give it focus. 2) Click on the empty menubar. Focus is incorrectly transferred to the lower textarea, which is a heavyweight component. This does not happen if the menubar is a JMenuBar. james.melvin@East 1999-06-02 This appears to be a lightweight component focus traversable problem. Motif will not allow a FocusIn on a non-traversable widget. If lightweight and heavyweight components are mixed, the lightweight components are all non-traversable, as the container widget has heavyweight traversable children. If the container has traversable children, the container itself is not traversable according to Motif. A mouse click in the lightweight component will result in a call to requestFocus. Focus is set to the lightweight component by first setting XmNtraversableOn to False for all heavyweight components in the container. Only now is the lightweight component focus traversable and can accept focus. Afterwards, traversability is restored on the heavyweight components. So, this only works when requestFocus is called. The problem lies in the fact that requestFocus is NOT called in the case when **Motif** attempts to restore focus. The lightweight component is not traversable in this case, and focus is returned to the next traversable heavyweight component. james.melvin@East 1999-06-17 I am closing this as 'will not fix'. It is not possible with the current implementation of Java to mix heavy and lightweight components in this way. james.melvin@East 2000-05-15 Maybe not with the current one, but what about the new focus management implementation that's planned for Merlin? norbert.lindenberg@Eng 2000-05-15 Name: dmR10075 Date: 07/26/2002 Merlin focus redesign eliminated the problems described in this report. Bug is no longer reproducible: component doesn't loose focus when menu is selected. TextArea still looses its outline but it gets it back when menu gets closed. ###@###.### 2002-07-26 ======================================================================
26-07-2002