Red Hat Bugzilla – Full Text Bug Listing
|Summary:||When windows are maximized in Java, mouse will have an offset|
|Component:||java-1.7.0-openjdk||Assignee:||Omair Majid <omajid>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||20||CC:||acc-bugz-redhat, ahughes, chkr, dbhole, floydbarber, jerboaa, jstpierr, jvanek, omajid, rderooy, robin|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-01-14 20:19:40 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description torkildj 2013-03-05 07:02:35 EST
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:
Comment 1 Omair Majid 2013-03-05 13:38:12 EST
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?
Comment 2 torkildj 2013-03-05 17:06:51 EST
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?
Comment 3 Omair Majid 2013-03-05 17:21:41 EST
(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"  before running Java.  https://wiki.archlinux.org/index.php/Java#Impersonate_Another_Window_Manager
Comment 4 torkildj 2013-03-06 08:33:17 EST
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)
Comment 5 torkildj 2013-03-06 08:34:03 EST
Created attachment 705939 [details] When gnome-shell is replaced with metacity, it works
Comment 6 torkildj 2013-03-06 08:35:08 EST
This file from Oracle can be used as test case http://docs.oracle.com/javase/tutorial/uiswing/examples/components/MenuLookDemoProject/src/components/MenuLookDemo.java
Comment 7 tuxor 2013-03-07 17:27:19 EST
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.)
Comment 8 Robin Stocker 2013-04-16 12:34:00 EDT
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.
Comment 9 Omair Majid 2013-04-16 14:23:52 EDT
(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).
Comment 10 Robin Stocker 2013-04-17 07:36:08 EDT
(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
Comment 11 Jasper St. Pierre 2013-04-17 11:39:48 EDT
(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!
Comment 12 Fedora End Of Life 2013-12-21 06:52:55 EST
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.
Comment 13 Robin Stocker 2014-01-14 19:03:22 EST
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?
Comment 14 Omair Majid 2014-01-14 20:19:40 EST
Closing bug as FIXED.