JDK-5023533 : Regression: A gap exists between the title bar and the menu bar in Stylepad demo
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux
  • CPU: x86
  • Submitted: 2004-03-30
  • Updated: 2006-01-16
  • Resolved: 2006-01-16
Related Reports
Relates :  
Description
If you run the Stylepad demo on b44 linux-i586 build, a gap exists between JFrame's title bar and the Stylepad's menu bar.

This problem is only reproducible on linux platforms, and not reproducible on b43.

I am filing this bug against AWT as it seems like a platform dependent inset problem.

###@###.### 2004-03-30

The problem is locale independent.  I originally found this problem in ja locale, but could also reproducible in English.

I attach a screen shot of the problem for your convenience.  You will notice a thin gray rectangle between the Frame and the menubar.  If you resize the frame this area immediately goes away.  This screen shot was taken on RedHat 9 Gnome desktop.

###@###.### 2004-03-31

Comments
SUGGESTED FIX Name: dmR10075 Date: 04/02/2004 *** /tmp/geta12895 2004-04-02 16:06:42.000000000 +0400 --- XContentWindow.java 2004-04-02 16:06:38.000000000 +0400 *************** *** 67,73 **** newBounds.setLocation(-in.left, -in.top); } if (insLog.isLoggable(Level.FINE)) insLog.fine("Setting content bounds " + newBounds); ! boolean needHandleResize = !(newBounds.getSize().equals(getSize())); reshape(newBounds); if (needHandleResize) { handleResize(newBounds); --- 67,73 ---- newBounds.setLocation(-in.left, -in.top); } if (insLog.isLoggable(Level.FINE)) insLog.fine("Setting content bounds " + newBounds); ! boolean needHandleResize = !newBounds.equals(getBounds()); reshape(newBounds); if (needHandleResize) { handleResize(newBounds); ###@###.### 2004-04-02 ======================================================================
02-04-2004

EVALUATION Name: osR10079 Date: 03/30/2004 I was unable to reproduce the problem using RedHat9/Metacity 2.4.34/C-locale. What Linux/Window Manager/locale do you use? ###@###.### 2004-03-31 ====================================================================== Name: dmR10075 Date: 04/02/2004 I was able to reproduce the bug on RH9/Metacity 2.4.34/UTF8/Bluecurve theme. ###@###.### 2004-04-02 ====================================================================== Name: dmR10075 Date: 04/02/2004 The bug is reproducible starting from b44. I have not found what caused the regression, but the behavior is the following: During initial frame setup, we receive several ConfigureNotify events. Among them, we notice insets change and set new insets. However, we don't generate RESIZED event due to optimization in XContentWindow.setContentBounds, since the size of content window hasn't changed. Removing optimization fixes the problem. The actual cause, the change which has been made between b43 and b44, is yet to be discovered. ###@###.### 2004-04-02 ====================================================================== Name: dmR10075 Date: 04/02/2004 The cause seems to be a thread race between insets change and insets query. This is how normal scenario looks like: java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 1704x1517)] on frame0 Insets: java.awt.Insets[top=25,left=5,bottom=5,right=5] java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 1704x1517)] on frame0 Insets: java.awt.Insets[top=25,left=5,bottom=5,right=5] java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 600x480)] on frame0 Insets: java.awt.Insets[top=20,left=6,bottom=6,right=6] java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 600x480)] on frame0 Insets: java.awt.Insets[top=20,left=6,bottom=6,right=6] and this is how bad scenario looks like: java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 1704x1517)] on frame0 Insets: java.awt.Insets[top=25,left=5,bottom=5,right=5] java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 1704x1517)] on frame0 Insets: java.awt.Insets[top=25,left=5,bottom=5,right=5] java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 600x480)] on frame0 Insets: java.awt.Insets[top=25,left=5,bottom=5,right=5] java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 600x480)] on frame0 Insets: java.awt.Insets[top=25,left=5,bottom=5,right=5] When COMPONENT_RESIZED arrives, we do validate(), as the result Swing relayouts JMenuBar into position depending on insets. Since insets are incorrect when we do all validates(), JMenuBar eventually remains at the wrong position. When insets become changed earlier, third and fourth validates() moves JMenuBar into correct position. I am able to see both scenarios with workspace, which confirms that this is a race. I was also able to reproduce the bug with b43, but it takes more times to run the program. ###@###.### 2004-04-02 ====================================================================== Name: dmR10075 Date: 04/02/2004 This is actually a regression from the fix for 4942457 ###@###.### 2004-04-02 ======================================================================
02-04-2004