GNOME Bugzilla – Bug 650512
Java applications appear to have incorrect widget coordinates when in maximized
Last modified: 2021-07-05 14:20:39 UTC
Created attachment 188055 [details] Example Java application Description: With any java application I've tried so far, when maximized, various events which rely on the coordinates of the various widgets of the application work incorrectly. The most noticable examples are - The cursor does not change correctly over a text field - Popups appear noticably displaced from where they should appear - Menus open at the wrong position (even on the wrong screen in dual head mode) Reproduce: 1. Compile the simple test application attached 2. Run java Test, and maximize the window 3. Notice that, when moving the mouse over the text field, in large portions of it the cursor is a pointer instead of a caret-cursor. Notes: - The "internally stored" geometry of the widgets seems related with their position before the application was maximized. - All Java apps appear to be affected, but only java apps as far as I can tell - Other window managers I tested (metacity, compiz, kwin) do not have this issue Version: gnome-shell-3.0.1-4.fc15.x86_64
So, this is a dup of bug 647866, but maybe we want to try to work around it somehow. You should also file a bug against java though, since it really seems like the bug is on their side. (The fact that it doesn't show up in other window managers just means that they are making some assumption which is not valid, but which happens to hold under those other window managers. This is not the first time java has had this problem. And as noted in bug 647866, there are related bugs even under plain metacity.)
Appears to have been reported some six years ago (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6242833) but I don't know what happened to the fix they mention (issue still present with their latest JDK1.6 and JDK1.7 snapshot).
Please add a workaround to this bug. As Sandro wrote, the bug was reported about six years ago, so it is very unlikely that it will be fixed soon. However, it renders Gnome 3 pretty unusable for Java developers. Is there a way I can work around it on user side for the time being?
I am not convinced that the linked-to bug is actually talking about this; the reporter seems to only be saying that the cursor shape is incorrect, not that the behavior is incorrect. (The last comment talks about this bug, but I think that commenter was confused about what the original bug was.) Anyway, as mentioned in comment 1, we would probably work around this if we could, but we have no idea how to. Someone needs to figure out exactly what crazy insane thing java is doing first.
Unfortunately I don't know how window managers work internally. However, Sandro said: "The "internally stored" geometry of the widgets seems related with their position before the application was maximized." I see the same behaviour. When I move the window somewhere to the top edge, then maximize it, then try to use the menus, the mouse cursor seems to be off by the same distance the window was placed before maximizing. So, when I move the window to the top left corner first, and then maximize it via Alt-F10, everything seems to be fine. Maybe a workaround would be to notify Java that the window was moved to the top left corner, before it is maximized? At least this would help Java users on Gnome 3 until you figured out the exact reason. Other programs shouldn't be affected by the change too, as they do not seem to care about the previous window position at all when maximized...
I have tried playing around a bit with libwnck to see whether the issue appears when maximizing/minimizing with those routines (which is what is used by compiz aka gtk_window_decorator as far as I could see from their sources - note: the issue does not appear with compiz). While the issue still appears with wnck_window_maximize, I found that if I call wnck_window_set_geometry with some geometry immediately afterwards, the issue does not appear. From the libwnck sources, I see that maximize and minimize reduce to XSendEvent with message _NET_WM_STATE, while wnck_window_set_geometry reduces to XSendEvent with message _NET_MOVERESIZE_WINDOW. I guess therefore to force Java windows to renegotiate their internal geometry, a _NET_MOVERESIZE_WINDOW event is necessary in addition to the _NET_WM_STATE event.
*** Bug 648363 has been marked as a duplicate of this bug. ***
*** Bug 668175 has been marked as a duplicate of this bug. ***
Unconfirmed for such a bug since May 2011?
*** Bug 681303 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.