JDK-4401846 : fvwm/fvwm2: Frame's title bar, icons appear offscreen [content pane is at (0,0)]
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.0,1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,solaris_7,solaris_8
  • CPU: x86,sparc
  • Submitted: 2001-01-04
  • Updated: 2017-05-16
  • Resolved: 2003-08-20
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.
5.0 tigerFixed
Related Reports
Duplicate :  
orig synopsis:  "Jpanel Appears on screen with wm icons and title off screen (fvwm and fcwm2)"

Name: boT120536			Date: 01/04/2001

java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

import javax.swing.*;
import java.awt.*;
import java.awt.event.*;

public class SimpleButtonExample2 extends JFrame implements ActionListener {

    private String labPrefix = "Number of button clicks: ";
    private int numClicks = 0;
    private JLabel label = new JLabel(labPrefix + "0  ");

    public SimpleButtonExample2 () {
        super("Simple Button Example");

        JButton qbutton = new JButton("Quit");
        qbutton.addActionListener(new QuitButtonListener());

        JButton cbutton = new JButton("Press Me");

        JButton cbutton2 = new JButton("Another");

        // Create a panel to place the buttons onto
        JPanel pane = new JPanel();

        // now add the panel to the content pane of the frame


    public void actionPerformed(ActionEvent e) {

        if (e.getActionCommand().equals("PressMe")) {
           label.setText(labPrefix + numClicks);
        } else {
           // Trying out the key-mask

           System.out.println("Another button pressed");


    public static void main(String[] args) {
        SimpleButtonExample2 app = new SimpleButtonExample2();


    class QuitButtonListener implements ActionListener {
        public void actionPerformed(ActionEvent e) {


Window Manager Title and buttons not on screen, when java SimpleButtonExample2
is started.
It seems to place the window and then it is repositioned with the title etc off

Seems to work ok with sawmill and twm it does not exibit the problem however
fvwm and fvwm2 do.

Solaris 7 and 8 tried with jdks 1.3.0 1.3.0_01 problem does not occur with
jdk 1.2.1_04
Not repeatble on linux 1.3.0_01 and 1.2.2.
(Review ID: 114578) 

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b28

SUGGESTED FIX *** /export/bino/t1/webrev/src/solaris/classes/sun/awt/X11/XToolkit.java- Tue Oct 21 14:38:03 2003 --- XToolkit.java Tue Oct 21 13:55:58 2003 -------------------------------------------------------------------------------- *** 286,295 **** --- 286,298 ---- } else { return val; } } + static native String getEnv(String key); + + static String getAWTAppClassName() { return awtAppClassName; } public static final String DATA_TRANSFERER_CLASS_NAME = "sun.awt.X11.XDataTransferer"; *** /export/bino/t1/webrev/src/solaris/classes/sun/awt/X11/XWM.java- Tue Oct 21 14:38:03 2003 --- XWM.java Tue Oct 21 13:45:46 2003 -------------------------------------------------------------------------------- *** 1208,1219 **** --- 1208,1234 ---- } /* * Some buggy WMs ignore window gravity when processing * ConfigureRequest and position window as if the gravity is Static. * We work around this in MWindowPeer.pReshape(). + * + * Starting with 1.5 we have introduced an Environment variable + * _JAVA_AWT_WM_STATIC_GRAVITY that can be set to indicate to Java + * explicitly that the WM has this behaviour, example is FVWM. */ + + static int awtWMStaticGravity = -1; static boolean configureGravityBuggy() { + + if (awtWMStaticGravity == -1) { + awtWMStaticGravity = (XToolkit.getEnv("_JAVA_AWT_WM_STATIC_GRAVITY") != null) ? 1 : 0; + } + + if (awtWMStaticGravity == 1) { + return true; + } + switch(getWMID()) { case XWM.ICE_WM: /* * See bug #228981 at IceWM's SourceForge pages. * Latest stable version 1.0.8-6 still has this problem. *** /export/bino/t1/webrev/src/solaris/native/sun/xawt/XToolkit.c- Tue Oct 21 14:38:04 2003 --- XToolkit.c Tue Oct 21 14:31:01 2003 -------------------------------------------------------------------------------- *** 954,958 **** --- 954,981 ---- } else { isComponent = JNI_FALSE; } return isComponent; } + + /* + * Class: sun_awt_X11_XToolkit + * Method: getEnv + * Signature: (Ljava/lang/String;)Ljava/lang/String; + */ + JNIEXPORT jstring JNICALL Java_sun_awt_X11_XToolkit_getEnv + (JNIEnv *env , jclass clazz, jstring key) { + char *ptr = NULL; + const char *keystr = NULL; + jstring ret = NULL; + + keystr = (*env)->GetStringUTFChars (env, key, 0); + if (key) { + ptr = getenv(keystr); + if (ptr) { + ret = (*env)->NewStringUTF(env, ptr); + } + (*env)->ReleaseStringUTFChars (env, key, (const char*)keystr); + } + return ret; + } + *** /export/bino/t1/webrev/make/sun/xawt/mapfile-vers- Tue Oct 21 14:38:04 2003 --- mapfile-vers Tue Oct 21 14:34:00 2003 -------------------------------------------------------------------------------- *** 247,256 **** --- 247,257 ---- Java_sun_awt_X11_XInputMethod_adjustStatusWindow; Java_sun_awt_X11_XlibWrapper_XQueryPointer; Java_sun_awt_X11_XlibWrapper_XFreeCursor; Java_sun_awt_X11_XToolkit_getDefaultXColormap; Java_sun_awt_X11_XToolkit_getDefaultScreenData; + Java_sun_awt_X11_XToolkit_getEnv; Java_sun_awt_X11_XlibWrapper_XCreateBitmapFromData; Java_sun_awt_X11_XlibWrapper_XFreePixmap; Java_sun_awt_X11_XlibWrapper_XAllocColor; Java_sun_awt_X11_XlibWrapper_XCreatePixmapCursor; Java_sun_awt_X11_XlibWrapper_XQueryBestCursor; ###@###.### 2003-10-21

EVALUATION According to the report, it sounds like this test works fine with Sawfish and dtwm, and has problems only with fvwm and fvwm2. eric.hawkes@eng 2001-01-04 See also 4457472. Commit to fix in Tiger. eric.hawkes@eng 2001-05-18 Reproducible on build 1.4.0-beta_refresh-b70. mike.bronson@eng 2001-07-11 Name: vuR10080 Date: 08/02/2002 ###@###.### 2002-08-02 This is an fvwm2 bug, it ignores gravity when handling ConfigureRequest's. $ wish % wm geometry . 200x200+0+0 % wm geometry . +1+1 That request to move window to +1+1 will move the window title off-screen. We have a code to work around this problem that is activated for E! and IceWM, but I feel this is the wrong thing to do - when the gravity bug is fixed, the workaround will cause problems. Since there are several popular WMs with this bug, perhaphs the workaround shall be conditionalized on a property or an environment variable. ====================================================================== Name: vuR10080 Date: 08/06/2002 ###@###.### 2002-08-06 A reply from Dominik Vogt <###@###.###>: | To resolve that issue, there is only one way that works: Don't | change the window position after the window was mapped. Let me | explain the reason behind this. | | Like most of the problems where the application and the WM | disagree, it starts with the ICCCM2. In the section about initial | window hints ( describes how to interpret the wanted | position and gravity: | | The win_gravity may be any of the values specified for | WINGRAVITY in the core protocol except for Unmap : | [snip] | It specifies how and whether the client window wants to be | shifted to make room for the window manager frame. | | This is what you expect to happen in a ConfigureRequest too, and | this interpretation is indeed backed by the ICCCM2 in section | 4.1.5: | | ... | The border width to be used and win_gravity position hint to be | used are those most recently requested by the client. Client | configure requests are interpreted by the window manager in the | same manner as the initial window geometry mapped from the | Withdrawn state, as described in section | ... | | So much for the theory. In real life, this rule is ignored more | often than honoured for several reasons: | | 1) A lot of application developers never read the ICCCM2. | 2) Many of those who did probably never noticed the well hidden | implications about window placement. | 3) The man page for XMoveWindow uses slang that is misleading | and never defined: | | The x and y members are used to set the window's x and y | coordinates, which are relative to the parent's origin and | indicate the position of the upper-left outer corner of | the window. | | This sounds as if the top left corner gets the requested | position, but it means that the top left pixel of the window | border is placed at said position. It can be easily | misunderstood. | 4) The ICCCM2 rule is just plain inconvenient: If an application | uses e.g. XMoveResizeWindow(), it has to find out the position | of the WM frame first, which is no easy task (unless you read | the ICCCM2 carefully and know about the WM_STATE atom). Many | applications use XMoveResizeWindow() even if the window did | not move. It's much more convenient to just set the current | window position again in that request. In theory, the same | effect would better have been achieved with StaticGravity, but | then the user can override gravity in the .Xdefaults, so that | wouldn't help. | 5) Some applications totally freak out when the ICCCM2 rule is | followed. They may set their position again and again, slowly | moving themselves off screen. | | To sum it up: it started with lousy documentation being | misinterpreted and then got out of hand. A few years ago, window | managers that followed the ICCCM2 rule were considered buggy. But | then came KDE, GNOME and Java, ignoring that tradition and clinged | to the letters of the ICCCM2. Nowadays we have many, many old | school window managers that don't work well with Java and a few | new window managers that do. Ironically, I believe that Java is | the the main reason for that move towards honouring the spec. | | To sum up the summary: the set of all window managers is split | into two factions, one that ignores the ICCCM2 and one that | honours it. Now that this is a fact, an application that wants to | behave has several options: | | * Implement highly sophisticated heuristics to guess which way | the window manager works. This probably involves creating a | test window and moving it around, but whatever you do, you can | always make a mistake. For example if the window manager does | not allow that the application moves some of its windows (fvwm | has an option for this). Or if the user choses a different | desktop theme that changes the size of the window decorations. | This is the approach Java has taken with the hard coded MWM | handling. In general it's unreliable. | | * Never move its windows. This is an easy to implement solution. | Many users would appreciate this. There are only few things | more annoying than applications that know better than the user | where their windows should be placed. You may think this | position is somewhat strict. But in the end, the *window | manager* is resposible for window placement, not the | application. | | * Withdraw the window, then move it, then map it again. This | solution is sub optimal for two reasons: It causes the window | to flicker and, worse, lets the window manager place the window | from scratch. If program specified placement is disabled | (which is a frequently used option in window managers), the | window ends up in a random position. And no, using the | USPosition hint is no solution because it's (a) forbidden by | the ICCCM2 and (b) the user can chose to override this option | too. Overall, I'd not recommend this solution. | | I'm willing to provide any assistance to resolve this issue. Just | contact the mailing list (###@###.###). ====================================================================== AWT already can deal with both WM behaviors but need a way to detect if the running WM implements strict ICCCM behavior or StaticGravity behavior. AWT already tries to detect some of the WMs that are known to implement the StaticGravity behavior, but this approach doesn't scale well. Unfortunately there's no standardized (neither de-jure, nor de-facto) way to detect at run time which behavior the window manager implements. We propose to introduce an environment variable _JAVA_AWT_WM_STATIC_GRAVITY that a user can set to indicate that his window manager implements StaticGravity behavior. This will be available in J2SE 1.5. ###@###.### 2003-08-21 The Activity Rating is High for FVWM at http://www.plig.org/xwinman/fvwm.html This bug has been fixed in MToolkit, but *not* in XToolkit. Since XToolkit will be the default on Linux, I think this bug should also be fixed on XToolkit. It should be taken out of the Integrated state until it is Integrated into XToolkit, the default AWT Toolkit for J2SE 1.5 on Linux. ###@###.### 2003-09-29 I have ported the fix to XAWT. See suggested fix for details. ###@###.### 2003-10-21