Sway: Java AWT does not focus on hover

[Hello71]

• Sway Version:

  • sway version v1.5, wlroots 0.11.0

• Debug Log:

  • available upon request

• Configuration File:

  • default

• Stack Trace:

  • N/A

• Description:

  • Run two copies of the below Java program. Focus one text box in one and one text box in the other. Move your cursor between the two windows, or use Mod4+h/l, then enter text.
  • Expected behavior: Upon mouse over of the inactive window, the text box most recently focused is re-focused and receives keyboard input.
  • Actual behavior: The text box is not focused and keyboard input is not registered until a click is performed anywhere in the window.

I assume this is caused by Java AWT trying to do its own focus management. With xwininfo, I can see that Java registers multiple X windows, including a "focus helper" in addition to the actual content windows. Using xev -id, I see that sway initially sends events to the content windows, but after a click, all input goes to the focus helper.

[Geo25rey]

Java AWT is deprecated.

Edit: for the specific reason that AWT windows act differently depending on operating environment. It is recommended that you use JavaFX instead. Plus, I don't believe AWT has a Wayland backend. It's probably using XWayland.

[fluix-dev]

Have you tried running with _JAVA_AWT_WM_NONREPARENTING=1?

[Hello71]

Java AWT is deprecated.

kinda, sorta, not exactly, but that's a worthless response either way. you may as well go around to every xwayland issue and comment "X is deprecated". it's a waste of everybody's time.

Have you tried running with _JAVA_AWT_WM_NONREPARENTING=1?

that applies mainly to output, not input.

neither of these comments are helpful, and it seems to me that no serious diagnosis was attempted, since otherwise the first comment should have been "where is the program". for what it's worth, here is the program, despite my skepticism that further comments will actually take it into consideration before dispensing generic criticism based solely on the issue title.

import java.awt.*;

class TextFieldExample {
    public static void main(String args[]) {
        Frame f = new Frame();
        TextField t1 = new TextField();
        t1.setBounds(50, 100, 200, 30);
        TextField t2 = new TextField();
        t2.setBounds(50, 150, 200, 30);
        f.add(t1);
        f.add(t2);
        f.setSize(300,300);
        f.setLayout(null);
        f.setVisible(true);
    }
}

[fluix-dev]

Sorry for the generic comment beforehand, but I can't replicate your problem. What JDK version are you using?

Also, while you mention that neither of us have performed serious diagnosis (true, sorry), you also didn't include the debug log that is specifically asked for in the issue template. Please provide one.

Edit: Also, maybe provide the runs of xwininfo and xev -id since you got what you believe is useful information out of them.

[Geo25rey]

In my attempt at reproduction, the behavior was inconsistent. Sometimes, it works as expected. Other times, it doesn't focus properly, but it only happens between the 2 AWT windows. This seems like some kind of race condition in either XWayland and/or AWT.

Regarding your test program, there is no way to close the window. I've made some additions to enable this below.

import java.awt.*;
import java.awt.event.*;

public class AWT {
    public static void main(String args[]) {
        Frame f = new Frame();
        TextField t1 = new TextField();
        t1.setBounds(50, 100, 200, 30);
        TextField t2 = new TextField();
        t2.setBounds(50, 150, 200, 30);
        f.addWindowListener(new WindowAdapter(){
            public void windowClosing(WindowEvent e) {
                f.dispose();
            }
        });
        f.add(t1);
        f.add(t2);
        f.setSize(300,300);
        f.setLayout(null);
        f.setVisible(true);
    }
}

[fluix-dev]

Regarding your test program, there is no way to close the window. I've made some additions to enable this below.

Why?

[Geo25rey]

Why?

Initially the window close listener does nothing. So you have to explicitly set it to dispose of the frame, since it's not a true window in AWT (one of the quarks of AWT).

Also, there is the start of a wayland backend for JavaFX here, but it hasn't been updated in 4 years, if you are seriously interested in using a Java-based GUI. Another thing I found was this conversation about a JavaFX wayland compositor.

[Hello71]

Upon closer investigation of the sway debug log, I noticed this message:

[DEBUG] [xwayland/xwm.c:1307] unhandled X11 event: 10

I recompiled wlroots with ICCCM support (off by default on Gentoo), and it resolved the filed issue, despite still showing that message. It also shows new messages about WM_HINTS, which I think is important. I guess this issue is partially user error, but I think it should be clearer that ICCCM support is important for certain clients and missing support may cause silent lack of features.

[emersion]

neither of these comments are helpful, and it seems to me that no serious diagnosis was attempted

Please stay civil. People commenting on the bug tracker aren't paid to help you.

Maybe we should just hard-require xcb-icccm in wlroots.

[Geo25rey]

Maybe we should just hard-require xcb-icccm in wlroots.

All features are enabled by default. Maybe when Gentoo compiles wlroots, they don't pass in the "-Dauto_features=enabled" command line argument into meson when building?

[Geo25rey]

I just looked into the way that Gentoo builds wlroots and they do indeed leave out the "-Dauto_features=enabled" flag. Here is a link to the package repo. In the meantime, I'm gonna look into how to contribute to this package repo to hopefully get this fixed.

Edit: For the record, Gentoo has xcb-icccm support but doesn't have xcb-util-errors support.

[Hello71]

neither of these comments are helpful, and it seems to me that no serious diagnosis was attempted

Please stay civil. People commenting on the bug tracker aren't paid to help you.

I'm just saying that a non-serious attempt at helping isn't really a significant improvement over no help at all, and that given that I clearly put in more than a token attempt at a bug report, I would appreciate more than a token response. I appreciate the more serious attempts at help afterwards.

Maybe we should just hard-require xcb-icccm in wlroots.

As a Gentoo user, I do like things to be configurable, but I don't like them resulting in silent non-obvious missing functionality. I think it would be better to show some message in this case, but I'm not sure that compositor stderr output is sufficiently visible. Another option might be to simply enable it by default, and write in the option help that it is strongly recommended for full X operation.

[Geo25rey]

@Hello71 The root of this problem is that the xcb-util-errors package isn't in the Gentoo package repo.

[fluix-dev]

I'm not sure that compositor stderr output is sufficiently visible.

The debug log will contain this so it should be visible enough for people that read the issue template (and thus their log) before posting.

[emersion]

given that I clearly put in more than a token attempt at a bug report, I would appreciate more than a token response

You're mistaken. Even if you put some effort into a bug report it doesn't mean volunteers have a duty to put some effort into helpful replies. The only way you can reliably expect your bug to be fixed is by sending a patch yourself to the appropriate project.

[Hello71]

I'm not sure that compositor stderr output is sufficiently visible.

The debug log will contain this so it should be visible enough for people that read the issue template (and thus their log) before posting.

Assuming that users actually read the log, put in the effort to file a complete bug report, and decide to read the entire log (of which this warning message would presumably be in the middle of, not at the start or end).

given that I clearly put in more than a token attempt at a bug report, I would appreciate more than a token response

You're mistaken. Even if you put some effort into a bug report it doesn't mean volunteers have a duty to put some effort into helpful replies.

Maybe, maybe not. I believe we have different opinions on that front, but I don't care to argue that here, beyond commenting that your general culture of hostility contributes to my next point.

The only way you can reliably expect your bug to be fixed is by sending a patch yourself to the appropriate project.

That's where you're wrong. I've sent in more than my share of ignored patches, on GitHub and elsewhere. Your premise is flawed, and your assumption of universality (all projects operate this way, therefore I am justified in assuming that everybody operates this way) and conclusion (hostility to those who do not start with a patch) I am certain drives away potential contributors. Regardless, I got what I needed, and you haven't bothered to respond to any of the substantive issues raised, so I guess we're done here.