Bug 918055 - When windows are maximized in Java, mouse will have an offset
When windows are maximized in Java, mouse will have an offset
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: java-1.7.0-openjdk (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Omair Majid
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-05 07:02 EST by torkildj
Modified: 2014-01-14 20:19 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-14 20:19:40 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The mouse has an offset compared to selected menu item (22.33 KB, image/png)
2013-03-05 07:02 EST, torkildj
no flags Details
Problem also happening with gnome-shell (3.27 MB, video/ogg)
2013-03-06 08:33 EST, torkildj
no flags Details
When gnome-shell is replaced with metacity, it works (2.53 MB, video/ogg)
2013-03-06 08:34 EST, torkildj
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 679542 None None None Never
Icedtea Bugzilla 1400 None None None Never

  None (edit)
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" [1] before running Java.

[1] 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 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.

Note You need to log in before you can comment on or make changes to this bug.