JDK-4333014 : REGRESSION: Window has Frame decorations in CDE
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.0,1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_7
  • CPU: generic
  • Submitted: 2000-04-25
  • Updated: 2000-05-09
  • Resolved: 2000-05-09
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 Other
1.3.0Fixed 1.4.0 betaFixed
Related Reports
Relates :  
Description

Name: dsR10078			Date: 04/25/2000

###@###.###
 
The fix for the bug #4313607 introduced a serious regression:
Window has Frame decorations in CDE.

The problem can be reproduced with the following test case:

----------------- Test.java ---------------------------
import java.awt.Window;
import java.awt.Frame;

public class Test {

    public static void main(String[] args) {
        final Frame frame = new Frame();
        final Window window = new Window(frame);
        window.setBounds(100, 100, 300, 300);
        window.setVisible(true);
    }
}
-----------------------------------------------------
 
======================================================================

Name: dsR10078			Date: 05/03/2000

###@###.###

Under fvwm Windows always had decorations.

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

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kest-sol-beta merlin-beta FIXED IN: kest-sol-beta merlin-beta INTEGRATED IN: merlin-beta
14-06-2004

EVALUATION Regression. Must fix for Merlin-beta and Kestrel-Solaris. eric.hawkes@eng 2000-04-25 Name: dsR10078 Date: 05/04/2000 ###@###.### Before the fix for #4313607 MWindowPeer.setResizable() call from MWindowPeer.init() was a nop. This is because setResizable() compares current value of wdata->isResizable and the new passed value and doesn't proceed if they match. They always match in this case since in create() we initialize wdata->isResizable with a value of the corresponding Java field winAttr.isResizable and then in init() we call setResizable() with the same winAttr.isResizable as an argument. Non-resizablility was established at the Motif level only on the first reshape after the shell widget is reparented. This delay caused the bug #4313607. Actually before the fix we never set resizability for a Window at the Motif level since its native shell widget is never reparented. This didn't cause real problems, however, since Windows don't have decorations anyway. The fix for #4313607 changed the resizability update scheme, so that the initial setResizable() always updates the resizability at the Motif level. To make a shell widget non-resizable under CDE we set a fixed subset of MWM decorations for it. So a Window receives non-resizable Frame's decorations. ======================================================================
11-06-2004

WORK AROUND Name: dsR10078 Date: 04/25/2000 ======================================================================
11-06-2004

SUGGESTED FIX Name: dsR10078 Date: 05/04/2000 ###@###.### In MWindowPeer.init() check winAttr.decorations field and call setResizable() only if this top-level has a full set of decorations that indicates an ordinary Frame or Dialog. This way we prevent setResizable() from being ever called for Window and InputMethodWindow, which is the desired behavior. The second is to initialize wdata->isResizable with true value instead of the inverse value of winAttr.isResizable. This way we miss the initial awt_util_setShellResizable() call for resizable Frames and Dialogs, but it seems that it is not needed, since all Frames and Dialogs are initially resizable anyway. --- MWindowPeer.java Thu Apr 27 17:27:19 2000 *************** *** 92,98 **** } pSetTitle(winAttr.title); ! setResizable(winAttr.isResizable); setSaveUnder(true); --- 92,100 ---- } pSetTitle(winAttr.title); ! if (winAttr.decorations == MWindowAttributes.AWT_DECOR_ALL) { ! setResizable(winAttr.isResizable); ! } setSaveUnder(true); --- awt_TopLevel.c Thu Apr 27 17:43:42 2000 *************** *** 1794,1804 **** /* * Fix for BugTraq ID 4313607. * Initial resizability will be set later in MWindowPeer_setResizable() ! * called from init(). But the real changes will be made only if the new ! * and old resizability values are different at that point, so we ! * initialize isResizable with inverse value here to get the job done. */ ! wdata->isResizable = !resizable; wdata->isFixedSizeSet = False; #if 0 --- 1794,1802 ---- /* * Fix for BugTraq ID 4313607. * Initial resizability will be set later in MWindowPeer_setResizable() ! * called from init(). */ ! wdata->isResizable = True; wdata->isFixedSizeSet = False; #if 0 ======================================================================
11-06-2004