User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061025 Firefox/2.0 Build Identifier: Sun's Java JDK version 1.6 is approaching it's final version and xfwm4 does not appear to correctly place Swing-based JDialog frames above it's parent JFrame when multiple Java Frames are open. Sun JDK 1.6 JDialog z-order behavior appears to work correctly on other window manager including metacity, fluxbox, and Beryl. Please see the attached jar file which contains a simple Java test application which demonstrates the behavior described above. Reproducible: Always Steps to Reproduce: 1.Install the latest Sun JDK 1.6 binary from http://download.java.net/jdk6/binaries/ 2.Execute the java test jar from a terminal by typing "java -jar xfwm4-jdk6-test.jar" without the quotes 3.Upon executing xfwm4-jdk6-test.jar, click on the "Open MDI Frames" button which will open 9 MDI type JFrames. 4. Each MDI JFrame contains a button named "Show Dialog". Clicking on any of the Show Dialog buttons will open up a JDialog which will be hidden behind the JFrames. 5. One Alt-Tab will display the JDialog, but upon trying to click on the JDialog, focus will switch to the parent JFrame and the JDialog will be hidden again. Actual Results: The JDialog is hidden behind it's parent frame. Expected Results: The JDialog should be shown above it's parent frame and have focus.
Created attachment 847 xfwm4-jdk6-test.jar Jar contains the java source. Execute by running "java -jar xfwm4-jdk6-test.jar" with Sun Java JDK 1.6
It clearly triggers a bug, indeed.
Humm, I dunno what java 1.6 is doing, but it's really odd, just like if it was trying to restack windows by itself. It misbehave, somehow, with all WM I tried (kwin, icewm) but metacity... Odd.
OK, I think I understand what Java 1.6 is doing here... When the pop-up is shown, it builds a list of "transient_for" properties between all the existing mdi windows opened, in the z-order, and update their properties accordingly. It's clearly hacky IMHO, I guess they do that for the legacy WM that did not properly handled transient_for == root which means is supposed to mean transient for all windows of thesame group (which is what they are trying to achieve anyway). I could be wrong, though, it's just rough guesses.
Created attachment 848 Disable raising of client on WM_TRANSIENT_FOR property change Well, I think this is exactly what I describe. Here is the scenario: Java updates the WM_TRANSIENT_FOR property of its windows, by settings every window transient for the one that's just below it, in order to maintain the z-order, as most WM maintains transients above their parents (note that there is no obligation of doing so, it's just a common behavior between WM). When xfwm4 receives a WM_TRANSIENT_FOR property change, it raises the window above the parent to ensure that transients stays above parents. That causes a raise condition as the WM is updating the Z-order of the windows while Java is using the Z-order to update the transient for properties. I do think that what Java does here is not a good idea, ie change the TRANSIENT_FOR property on-the-fly for that purpose. Disabling the raise of transient on WM_TRANSIENT_FOR property change in xfwm4 fixes the issue with Java 1.6. But it's like "degrading" xfwm4 to make Java 1.6 happy :( See attached patch against current SVN trunk.
I've committed the patch to SVN trunk and xfce 4.2 branch.
I tested the patch and can confirm it resolves the issue for me as well and has made working with Java on xfce much more pleasant. Thank you for the great explanation and swift response.
maybe you should report a bug to java devs: http://www.oracle.com/technetwork/java/javase/bugreports-140511.html