Created attachment 705370 [details] The mouse has an offset compared to selected menu item Description of problem: When maximizing Java window in MATE (also seems to be same problem in Gnome3), the mouse will have an offset. This problem has previously been fixed in openjdk for Mutter, and it seems like Mint desktop mimics mutter to avoid this problem https://github.com/linuxmint/muffin/pull/11. Maybe the mutter.patch can be extended to include Gnome3 and MATE http://icedtea.classpath.org/hg/release/icedtea6-1.10/file/711c59eac969/patches/openjdk/mutter.patch Version-Release number of selected component (if applicable): F18 (64bit) How reproducible: Steps to Reproduce: 1. Maximize Swing application (ie Netbeans) 2. Open menu and hold mouse button (if not holding mouse button, it will dissapear immediately). Mouse position registered in java program now have a huge offset compared to actual mouse position. Actual results: Expected results: Additional info:
Okay, stuff not working under MATE makes sense. I am really surprised about GNOME, though. GNOME 3 (shell) uses mutter as the window manager. Do you run into this problem in stock GNOME 3 shell or are you running GNOME applications under MATE?
Hi Thanks for the quick reply. It was actually reported by my colleagues that it was broken under GNOME 3 too. But now that I think about it, they most likely used the official JDK from Oracle, so that is not patched at all. I could not reproduce on my PC with GNOME 3 and OpenJDK just now. Do you think the best strategy is to change Mate to mimic Mutter as the other window managers or to fix it directly in Java?
(In reply to comment #2) > Do you think the best strategy is to change Mate to mimic Mutter as the > other window managers or to fix it directly in Java? As far as I know, this is not a bug in Mate. It's OpenJDK that (for some strange reason) needs to know about the window manager. So the correct place for the fix would be OpenJDK too. It already has corner cases for metacity, mutter, kwin and others. As a workaround, you can use install the "wmname" package and run "wmname Metacity" [1] before running Java. [1] https://wiki.archlinux.org/index.php/Java#Impersonate_Another_Window_Manager
Created attachment 705938 [details] Problem also happening with gnome-shell I did some more testing today, and turns out Netbeans must implement some workarounds because it fails for all other java swing applications with gnome-shell. However when gnome-shell is replaced with metacity it will work (however gnome menu disappears and desktop is effective useless)
Created attachment 705939 [details] When gnome-shell is replaced with metacity, it works
This file from Oracle can be used as test case http://docs.oracle.com/javase/tutorial/uiswing/examples/components/MenuLookDemoProject/src/components/MenuLookDemo.java
I run into this problem with jEdit (http://www.jedit.org/). It renders the top menu bar literally unusable. But what seems to be a workaround for now is running "wmname LG3D" before running the java software. (I don't have oracle's JDK, only latest java-1.7.0-openjdk from the repositories.)
The bug about this on GNOME Bugzilla is (can't edit "See Also"): https://bugzilla.gnome.org/show_bug.cgi?id=679542 From there: """ Comment 4 Jasper St. Pierre [gnome-shell developer] 2013-01-24 17:31:47 CET http://hg.openjdk.java.net/jdk8/awt/jdk/file/7cda96a78260/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java On line 723 in this file (I can't link to the line directly) is where they check for Mutter. """ So it's definitely a bug in OpenJDK. Either it should include "GNOME Shell" in the check or the check should be removed (see TODO before check). @Omair: Should this be reported against IcedTea so we can fix it there? I'm not sure reporting it on bugs.sun.com will result in anything, it feels a bit like a black hole.
(In reply to comment #8) > So it's definitely a bug in OpenJDK. Either it should include "GNOME Shell" > in the check or the check should be removed (see TODO before check). Thanks for tracking down the root of the problem. Removing the TODO is a long-standing problem with probably significant changes. The mutter fix should be trivial to implement, however. > @Omair: Should this be reported against IcedTea so we can fix it there? Yes, please do file a bug. I will fix this in IcedTea (and send the fix to OpenJDK as well).
(In reply to comment #9) > > @Omair: Should this be reported against IcedTea so we can fix it there? > > Yes, please do file a bug. I will fix this in IcedTea (and send the fix to > OpenJDK as well). Done: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1400
(In reply to comment #9) > (In reply to comment #8) > > So it's definitely a bug in OpenJDK. Either it should include "GNOME Shell" > > in the check or the check should be removed (see TODO before check). > > Thanks for tracking down the root of the problem. Removing the TODO is a > long-standing problem with probably significant changes. The mutter fix > should be trivial to implement, however. May I ask what window managers are non-ICCCM compliant? That's basic ConfigureNotify semantics that GTK+ and Qt already implement without any known issues, as far as I'm aware. The AWT toolkit does all this complex event tracking and checking whether you're reparented, all stuff that the ICCCM (which Sun *also wrote*) said clients should not do, and no modern toolkit does it in response!
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
So, icedtea bug 1400 has been fixed and released and I can no longer reproduce the problem in Fedora 20. I think this bug can be marked as fixed, right?
Closing bug as FIXED.