JDK-6895647 : Frame may jump to an unpredicted location upon entering the non-opaque mode on X11
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2009-10-27
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
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.
JDK 7
7 b116Fixed
Related Reports
Relates :  
JDK-6849774 - Visible frame not becoming Transparent in Ubuntu
Description
The issue is close to 6849774.

Environment: ubuntu, compiz, latest jdk7.

Use the testcase attached to 6849774 to reproduce the problem:

1. The test shows the control frame (with two button) and the tested (undecorated) frame
2. Click the button "Not opaque"

3-a. Sometimes the tested frame correctly becomes transparent // the problem is not reproducible
3-b. Sometimes the background of the tested frame becomes white (not transparent) and the tested frame changes its location (it jumps to the bottom left corner of the screen or the upper right corner of the screen).
Comments
SUGGESTED FIX --- old/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java 2010-10-05 16:54:00.000000000 +0400 +++ new/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java 2010-10-05 16:54:00.000000000 +0400 @@ -87,11 +87,15 @@ } void postInit(XCreateWindowParams params) { + // The size hints must be set BEFORE mapping the window (see 6895647) + updateSizeHints(dimensions); + + // The super method maps the window if it's visible on the shared level super.postInit(params); + // The lines that follow need to be in a postInit, so they // happen after the X window is created. initResizability(); - updateSizeHints(dimensions); XWM.requestWMExtents(getWindow()); content = XContentWindow.createContent(this);
05-10-2010
EVALUATION The XDecoratedPeer.postInit() calls super method first. This causes the XComponentPeer.postInit() to map the window on the screen. And only after that happens, the XDecoratedPeer.postInit() calls updateSizeHints(dimensions); Placing the call before calling the super method eliminates the issue. Obviously there was a thread race, and sometimes compiz was able to display window too fast w/o knowning what exact location we want the frame to be in.
01-10-2010
EVALUATION The minimum test that reproduces the issue: import java.awt.*; import java.awt.event.*; public class test { public static void main(String[] args) { final Frame f = new Frame(); f.setLocation(50, 400); f.setSize(300, 300); Button b = new Button(); b.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { synchronized (f.getTreeLock()) { f.removeNotify(); f.addNotify(); } } }); f.setLayout(new FlowLayout()); f.add(b); f.setVisible(true); } } THis is reproducible when running Compiz window manager with appearance effects enabled only. Not reproducible with Metacity.
01-10-2010
EVALUATION The transparency-related issues are covered by 6848852. This CR is about the frame jumping to another location, probably due to peer replacement.
30-10-2009