JDK-5089312 : JComboBox (with heavyweight popup): Bottom border missing on first showing.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.0_ea,1.4.0,5.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_nt,windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2004-08-19
  • Updated: 2005-12-01
  • Resolved: 2004-12-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u2Fixed 6 b15Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description
I've noticed that the first time any JComboBox is shown that needs a heavyweight popup, the bottom border is missing. After the first time showing any popup, all JComboBoxes then behave properly. See attached screenshot (missing-border.bmp).

Steps to reproduce:
- Launch SwingSet2
- Switch to the JComboBox demo
- Resize the frame so that if one of the combos is shown it will use a heavyweight popup.
- Click on the JComboBox to show the popup.
- Notice that the bottom border is missing.

Note that if you show any menu or any popup (light or heavy) first, this problem will not appear.

Comments
SUGGESTED FIX In the awt_Window.cpp code, UpdateInsets, we should make calculations if toplevel is decorated only, otherwise should make the insets zero. So the fix is, to check just for decorations and do not check for instanceof target: the bug in question is due to a missed case of instanceof(java.awt.Window). ------- awt_Window.cpp ------- *** /tmp/sccs.RCkvKF 2004-10-27 16:23:56.000000000 +0400 --- awt_Window.cpp 2004-10-27 14:31:38.000000000 +0400 *************** *** 462,469 **** { /* This window hasn't been sized yet -- use system metrics. */ jobject target = GetTarget(env); - if (JNU_IsInstanceOfByName(env, target, "java/awt/Frame") > 0 || - JNU_IsInstanceOfByName(env, target, "java/awt/Dialog") > 0) { if (IsUndecorated() == FALSE) { /* Get outer frame sizes. */ LONG style = GetStyle(); --- 462,467 ---- *************** *** 487,492 **** --- 485,491 ---- /* fix for 4418125: Undecorated frames are off by one */ /* undo the -1 set above */ /* Additional fix for 5059656 */ + /* Also, 5089312: Window insets should be 0. */ ::memset(&m_insets, 0, sizeof(m_insets)); } *************** *** 495,501 **** ((AwtFrame*)this)->GetMenuBar()) { m_insets.top += ::GetSystemMetrics(SM_CYMENU); } - } m_insets.bottom += extraBottomInsets; env->DeleteLocalRef(target); } --- 494,499 ---- ###@###.### 10/27/04 12:25 GMT
27-10-2004

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
30-09-2004

EVALUATION The reason of this bug is that at the time when we are creating ComboBox popup for the first time AWT makes its window one pixel shorter than the actual size of the component inside it. This happens because at this time window top insets is set to -1. Here is the code from the awt_Window.cpp : else { m_insets.top = -1; } See also bug 5059656 that deals with the similar problem. ###@###.### 2004-08-25 As far as I remember that we already have bug about this problem, unfortunately I was unable to find it :( Anyway, we should try to fix this in mustang ###@###.### 2004-08-25 ###@###.### 2004-08-25
25-08-2004