Bug #4199374 was report against Win32 platforms and CTE engineer fixed ONLY on Win32 platforms. The problem is still reproducable in Linux and Solaris platforms. 

It failing on 1.3.1.xx, 1.4.1.xx, 1.4.2.xx, 1.5.0.

Need to be fixed ASAP



Component.requestFocus() fails on Solaris
======================================================================



Component.requestFocus() fails on Solaris


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

N/A

The problem is reproducible on 1.3.1, 1.4, 1.4.1 and 1.4.2 
Thus this is not a mantis or hopper regression.

  xxxxx@xxxxx   2003-04-23

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




First of all, the test for 4199374 in the exact from won't work with
any JDK starting with 1.4.0. In that test, a component (JTextField)
is inserted into a Window which has no visible owner. According
to 1.4 focus spec, such a Window cannot receive focus.

The test needs to be changed so that JFrame becomes JWindow's
owner. In that form, the problem, indeed, exists on Solaris and Linux.

However, on Linux this behaviour was fixed around 1.5.0 b15, at
least the test works fine on Linux with current builds (b29). This is
related to XAWT work, which, among other things, took care of
this problem.

On Solaris, we can't fix it in tiger and will request this bug to be
WAIVED. Once the XAWT toolkit becomes default on Solaris
(we expect this to happen in JDK 1.5.1), the problem will be
fixed on Solaris, too.

Below is the corrected test case:

===
  import java.awt.event.*;
  import javax.swing.*;
  public class Test {
    public static void main(String args[]) {
      final JFrame frame = new JFrame();
      JButton button = new JButton("Test");
      frame.getContentPane().add(button);
      frame.pack();

      frame.addFocusListener(new NoisyFocusListener("Frame"));
      button.addFocusListener(new NoisyFocusListener("Button"));

      button.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent e) {
          JWindow window = new JWindow(frame);
  //        JFrame window = new JFrame();
          JTextField field = new JTextField("Edit Me!");
          window.getContentPane().add(field);
          window.pack();

          field.addFocusListener(new NoisyFocusListener("Field"));
          window.addFocusListener(new NoisyFocusListener("Window"));

          window.setVisible(true);
          field.requestFocus();
        }
      });
      frame.setVisible(true);
    }

    static class NoisyFocusListener implements FocusListener {
      private String name;
      public NoisyFocusListener(String name) {
        this.name = name;
      }
      public void focusGained(FocusEvent e) {
        System.out.println(name + (e.isTemporary() ? " got temporary focus." : " got focus."));
      }
      public void focusLost(FocusEvent e) {
        System.out.println(name + (e.isTemporary() ? " lost temporary focus." : " lost focus."));
      }
    }
  }
===
  xxxxx@xxxxx  


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

We discussed this at the Tiger core team meeting today.  The general feeling 
was that we ought to try to fix the bug, but not in the Tiger timeframe.  
I'll commit this to Mustang.  

Since the customer was primarily concerned about Windows, I don't see this as 
a regression as long as the test continues to pass on Windows.  

Also, the test should be updated as suggested above.  

  xxxxx@xxxxx   2003-12-03
I think, we're free to close it now. MToolkit has gone.
Posted Date : 2007-10-30 17:29:39.0

This is a serious bug. Do you know when will this get fixed?

Based on what I've read here and in Bug #4199374 , I 
believe I am having a similar problem in that on Linux, 
running with Java 1.4.x under Linux and using Mozilla 
1.3.1, I cannot regain focus on a JTextfield in an applet 
after opening up a popup from the applet.  Imagine a 
applet with a button and a text field.  The button opens 
up a popup window (could be any window ie: Java 
window, browser window), which has a simple button 
to close the window.  If I click on the button, I can no 
longer regain focus on the JTextfield in the applet.
This bug does NOT exist in Java 1.3.x under Linux, and 
does not exist under the Windows environment using 
the same version of Mozilla.

Is this ever going to be fixed in 1.5.0 ?

I also have a same problem as ericchang591 mentioned.  It occurs on 1.6.0 too.  Any fix in the future?

This is still a problem on Linux64,  Java 1.6 Update 2.

Hi all,

Okay, I've some news about that bug:

First of all, I'm able to reproduce it with Java 6 update 10, both build 14 and 23. Well, I'm not sure what you expect as the error case but here is what I get on my Ubuntu 8.04, Intel Corporation Mobile 945GM/GMS, double Core2 T550 (Inspiron Dell 640m): when the program starts I the JTextFiled get focused so I can edit it. But if I click outside once, then I'm not able to focus it anymore using my mouse! On the contrary, I just check on Windows on a other computer (with Java 6 too) and I could set the focus again using the mouse! So yes the bug is still there in 2008!
	
Also, the only way I found to set back the focus in the JTextField programmatrically, was the following way (I'm not saying that's a fiw, I'm rather just telling it in case it may help you to hunt the bug):

public void focusLost(FocusEvent e) {
            System.out.println(name + (e.isTemporary() ? " lost temporary focus." : " lost focus."));
            if (field != null) {
                window.setVisible(true);// if you don't do this you can't gain the focus again; but that one seems      
                                        //expected after the focus spec since the field owner is a JWindow 
                                        //which isn't focusable.
                field.requestFocus();
            }
        }


Now, because of some comments I wondered whether it would work using Java 5. So I grabbed the last available java 5 (build 1.5.0_15-b04 ) I tried the test case. Wow! the JTextFiled case isn't even visible, indeed it looks like it's only 1 pixel x 1 pixel large! I tried some stuff like field.setSize(200, 200);window.setSize(300, 300); and also disabled window.pack(); but it didn't help.

				
Also, I tested this bug is because I highly suspect it's what is annoying Netbeans 6.1 users on Linux at least, see the following bug
http://www.netbeans.org/issues/show_bug.cgi?id=119617
Using all the jdk 1.6 I've tried (including update10 build 14 and 23), I got the editor focus lost occasionally, generally after an auto-completion popup dialog opens.

But using Java 1.5.0_15-b04 with Netbeans seems to fix the bug #119617 for me (never occurred again yet). While #4851685 still looks weird as I said.

So I would say there is probably a regression with Java 6 regarding this bug #4851685.

Could you please provide some kind of workarround/patch to avoid the problem? Not being able to use Netbeans decently on some Linux PC is very annoying indeed and won't make both Swing and Netbeans look solid.

Best regards,

Raphaël Valyi
www.smile.fr

Raphaël, thank you for the post. But it would be better if you file a bug against your particular problem and _provide_ some testcase. It's always difficult to understand what's going on from a phrase like "something fails because requestFocus() fails". requestFocus() is just a small peak and it can fail because of vaaarious reasons. Hope you see.

Anton.

Anton, 

sorry to insist, but I think that bug description exactly matches what I've been observing. The provided test case is exactly what fails for me on my Ubuntu Linux specifically with any JDK6 I tried. So I don't think I should open a new thread because I've no better bug description than this one anyway.

By the way, just like I jdk5 fixes the bug for me, jdk7 build 26 and above at least fixes the bug too. for Netbeans jdk7 edge is a better option for me and is okay to use.

I'm sorry if you can't reproduce the bug. If there is any simpler test you would like me to do on my PC, just ask. Regards,

Raphaël Valyi.

We are facing similar proble with Solaris.
Using  Compiler 1.4.2_18. and 
Solaris JRE 
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)

Let me know if any fix available.
akash bhimani
akash.bhimani@gmail.com