-
Bug
-
Resolution: Unresolved
-
P3
-
None
-
6u10
-
x86
-
windows_xp
FULL PRODUCT VERSION :
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
ver XP
EXTRA RELEVANT SYSTEM CONFIGURATION :
Tried with IE6 and IE8
A DESCRIPTION OF THE PROBLEM :
I have a JMenuBar in a JApplet.
The menubar contains a menu, which has as submenu and a JTextfield "A".
The submenu has antoher JTextfield "B".
Running the applet in a browser with width and height set to 250, both Textfields are editable.
Running the applet in a browser with height set to "45" the textfield in the submenu ("B") is not editable.
The problem occurs with IE6 and JRE 1.6.0_12, with JRE 1.5.0_09 it doesn't.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Use the code provided below and run the applet using a height of 250 in IE
=> Works fine!
2) Use the code provided below and run the applet using a height of 45 in IE
=> One of the textfields won't get a focus the other still does
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The JTextfield should behave the same - no matter how the applet is sized.
ACTUAL -
The JTextfield won't get a Focus if the applet is too small (Whatever "too small" is)
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import javax.swing.*;
public class Test extends JApplet {
public void init()
{
this.setJMenuBar(getTestMenuBar());
}
public JMenuBar getTestMenuBar()
{
JMenu test=new JMenu("test1");
JMenu test2=new JMenu("test2");
// This field seems to be always editable
JTextField tf=new JTextField("- A -");
// This field won't be editable if the applet has not enough height in IE
JTextField tf2=new JTextField("- B -");
test2.add(tf);
test.add(test2);
test.add(tf2);
JMenuBar erg=new JMenuBar();
erg.add(test);
return erg;
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
I don't know one.
Release Regression From : 5.0u9
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
ver XP
EXTRA RELEVANT SYSTEM CONFIGURATION :
Tried with IE6 and IE8
A DESCRIPTION OF THE PROBLEM :
I have a JMenuBar in a JApplet.
The menubar contains a menu, which has as submenu and a JTextfield "A".
The submenu has antoher JTextfield "B".
Running the applet in a browser with width and height set to 250, both Textfields are editable.
Running the applet in a browser with height set to "45" the textfield in the submenu ("B") is not editable.
The problem occurs with IE6 and JRE 1.6.0_12, with JRE 1.5.0_09 it doesn't.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Use the code provided below and run the applet using a height of 250 in IE
=> Works fine!
2) Use the code provided below and run the applet using a height of 45 in IE
=> One of the textfields won't get a focus the other still does
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The JTextfield should behave the same - no matter how the applet is sized.
ACTUAL -
The JTextfield won't get a Focus if the applet is too small (Whatever "too small" is)
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import javax.swing.*;
public class Test extends JApplet {
public void init()
{
this.setJMenuBar(getTestMenuBar());
}
public JMenuBar getTestMenuBar()
{
JMenu test=new JMenu("test1");
JMenu test2=new JMenu("test2");
// This field seems to be always editable
JTextField tf=new JTextField("- A -");
// This field won't be editable if the applet has not enough height in IE
JTextField tf2=new JTextField("- B -");
test2.add(tf);
test.add(test2);
test.add(tf2);
JMenuBar erg=new JMenuBar();
erg.add(test);
return erg;
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
I don't know one.
Release Regression From : 5.0u9
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.