How to fix Java applications mouse pointer offset in Awesome WM?

Question

How to reproduce in Awesome WM v3.5.2 through 3.5.5 (so far):

1. Install OpenJDK or Oracle Java 7. This bug has been observed with both.
2. Start a new Awesome WM session with the default configuration.
3. Start either jEdit or PyCharm. This bug has been observed with both.
   • Move the mouse pointer around, and observe how it changes based on whether you are hovering over code, project files or menus. This should work normally.
   • Click and release on the File menu, enter one of the sub-menu, and observe how the item directly under the mouse pointer is focused all the time.
4. Press Mod4+Space repeatedly until the floating layout is activated (the application will be almost full screen) or open another application in the same tag.

At this point, I would expect the mouse to behave like it does with "normal" applications. Instead I observe the following:

• When clicking and navigating menus with the mouse, the mouse pointer and the focused menu item will be vertically offset from each other, seemingly at the same amount of pixels as the height of the status bar.
• When hovering over miscellaneous items as before, the cursor icon will be set as if the mouse pointer was higher up on the screen. For example, hovering over the top line of text you will not see a text cursor.

It's as if something doesn't detect that the window coordinates have changed.

A similar but much more annoying bug happens when you open another application in the same tag - the mouse behaviour is as if the window hadn't moved at all.

When you toggle another tag which already has an application open - the "virtual mouse desktop" is moved to the top left of the primary screen.

Since these bugs have been observed in both OpenJDK and Oracle Java, with different Java applications, it seems very likely that the bug is in Awesome WM.

Related question, article. I tried the _JAVA_AWT_WM_NONREPARENTING and wmname fixes, but no go.

Answer 1

You need to add special definitions to the source for the window manager, in my experience.

I had this happen to me a couple of years ago in the MATE desktop's marco window manager; the 'fix' was to make marco pretend to be its parent project, metacity, to utilize the JDK's built-in fixes for metacity.

from src/core/display.c:

meta_prop_set_utf8_string_hint (the_display,
                                the_display->leader_window,
                                the_display->atom__NET_WM_NAME,
                                "Metacity (Marco)");

This fix reeks of what happened to the user agent string in the world of web browsers, but it worked for me.

Additionally, the arch wiki even mentions Awesome WM in the section on impersonating other window managers, where it recommends wmname:
https://wiki.archlinux.org/index.php/Java#Impersonate_another_window_manager

You may use the wmname from suckless.org to make the JVM believe you are running a different window manager. This may solve a rendering issue of Java GUIs occurring in window managers like Awesome or Dwm or Ratpoison.

$ wmname LG3D

You must restart the application in question after issuing the wmname command.

This works because the JVM contains a hard-coded list of known, non-re-parenting window managers. For maximum irony, some users prefer to impersonate LG3D, the non-re-parenting window manager written by Sun, in Java.

Answer 2

This seems to be known Java related bug on Linux: https://netbeans.org/bugzilla/show_bug.cgi?id=227754

On above URL you can find workaround for NetBeans IDE, workaround which works for Java app I use is to NOT maximize Java app by pressing maximize button, but to resize window manually to size you prefer. Please share info if this help you, thanks!