awesome

Welcome to awesome bug tracking system.
Tasklist

FS#973 - Menus of Java applications close when mouse is released

Attached to Project: awesome
Opened by Mika Fischer (mika.fischer) - Thursday, 08 March 2012, 15:42 GMT
Last edited by Uli Schlachter (psychon) - Friday, 06 July 2012, 18:27 GMT
Task Type Bug Report
Category Core
Status Closed
Assigned To No-one
Operating System Linux
Severity High
Priority Normal
Reported Version git/master
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

When clicking on the menu bar in a Java application (Matlab, Freemind, etc.), the menu opens, but closes again, as soon as the mouse button is released. Also, even when holding the mouse button, no items of the menu can be selected.

This works fine in 3.4.11, but is broken in master.
This task depends upon

Closed by  Uli Schlachter (psychon)
Friday, 06 July 2012, 18:27 GMT
Reason for closing:  Fixed
Additional comments about closing:  commit 29b09cf7da401f13335eb8f8ebb128c80454ecdd
Author: Uli Schlachter <psychon@znc.in>
Date: Fri Jul 6 13:37:58 2012 +0200

Ignore re-focusing the focused client

When something gives the input focus to the client which already has the input
focus, bad things can happen. Normally, you'd expect nothing to happen in this
case, but X11 is not that simple.

When updating the input focus and the focused client has the nofocus hint set,
we are actually taking away the focus from this client.

Hopefully this fixes  FS#973 .

Signed-off-by: Uli Schlachter <psychon@znc.in>
Comment by Mika Fischer (mika.fischer) - Thursday, 08 March 2012, 16:07 GMT
So what are you suggesting? I'm imagining things? Awesome is more right, and almost all other WMs where Java applications actually work, have it wrong? What am I supposed to do to get my applications to work in awesome?

If your answer is "We don't care about your applications. If they are buggy we have no intention whatsoever to work around them, even if they work in almost all other WMs." then please let me know so I can stop wasting my time here.
Comment by Alexander Yakushev (Alex.yakushev) - Thursday, 08 March 2012, 16:15 GMT
Okay, I got awesome/git and freemind right here. Menus are working perfectly.

Uli's right in every way. First, he is right in the technical part that WM and menus don't interfere. Second, he is right not running to "fix awesome" at your first call. Awesome is the system for technically advanced users who do not afraid to solve problems, which includes investigating an issue thoroughly instead of spamming the bug tracker with messages that are most likely to have the same root (all of them are Java-related). So, I think, yes, you should stop wasting your and everyone else's time here.
Comment by Mika Fischer (mika.fischer) - Thursday, 08 March 2012, 16:34 GMT
> he is right in the technical part that WM and menus don't interfere

While this might be true on some level it is still the fact that the menus work with 3.4.11 and don't work with master. Also note that this is the case for Uli as well as for me.

> Awesome is the system for technically advanced users who do not afraid to solve problems

I do indeed know that. I did not know that I'd have to be an X11 expert to even use awesome though, if I catch your drift correctly.

> which includes investigating an issue thoroughly

Which is what I'm trying to do here by reporting my problems. I don't have the expertise to debug this myself. If your reply to this is "Then what are you doing here using awesome", then fine I'll leave.

> instead of spamming the bug tracker with messages that are most likely to have the same root (all of them are Java-related).

1. I got told by Uli "one issue per 'issue'". So I opened different issues for things that I percieve as different errors.
2. Or maybe you're saying "The bug is that you're using Java". In which case I need to find a WM that works in the ugly ugly real world...

The main issue I have is with communication. I reported my problems seven weeks ago on the ML. I only got two "me too" replies. Then I report the issues in the bug tracker. Uli replies that it works with master but the menus are broken, I try the same and get the same results. So I report that the bugs are fixed in master and report a new bug for master about the menus. Which promptly gets closed with a message saying that it can't possibly be awesome's fault.

So what do you suggest my next step could be now? And "Stop using Java" or "Just don't use awesome then" are not the answers I'm looking for.
Comment by Alexander Yakushev (Alex.yakushev) - Thursday, 08 March 2012, 16:52 GMT
Sorry for my harsh response, but that is what you expect to get for blackmailing.

I'm not telling you to stop using Java. I use it every day myself and don't have any issues with it (Arch Linux, awesome/git). Still awesome has it's long history of relationship with Java so I do not deny you having troubles with it. Still I strongly suppose that it's neither Java's fault nor awesome's one. If you can't fix it then you should probably switch to another WM. And the best way to do it is to do it quietly without any drama.
Comment by Mika Fischer (mika.fischer) - Thursday, 08 March 2012, 16:56 GMT
Will do
Comment by Uli Schlachter (psychon) - Thursday, 08 March 2012, 18:43 GMT
> Still I strongly suppose that it's neither Java's fault nor awesome's one.

I think it certainly is java's fault. The "gray window" bug for example is java ignorring all events until it gets reparented by the window manager. Then it uses some (broken) heuristic for detecting non-reparenting WMs. When that heuristic is wrong, java will ignore all events forever and thus not paint its window when it is told to. This is certainly java's fault.

For this bug, I am sure that the problem is in java, too (the window manager has nothing to do with menus, doesn't even see them). However, digging into the java code to figuring out that other issue already took enough of my time and what were the results from that? I now know that this bug is java being stupid and I managed to find a several years old java bug report with some patches which is being ignored for years. In other words, Sun/Oracle doesn't really care about standards, they just care about java working on kde/gnome.
I am 99.9% sure that this issue is in java, too and I am in 99.9% sure that digging into java's source code to figure out what is going on is just a another waste of my time.

However, I reopened this issue. Let's just keep it open. Perhaps someone will eventually be bored enough to figure out what exactly java is doing wrong and will then write another patch which gets ignored. Perhaps no one will bother.
Comment by Anton (zhuravlik) - Saturday, 30 June 2012, 18:37 GMT
Was introduced in commit http://git.naquadah.org/?p=awesome.git;a=commit;h=ba64f3c3cd9e1cded99e1677ee6aa21cfa3cd078.

See  FS#1012 .
Could be fixed by simply undoing changes of that commit.
Comment by Uli Schlachter (psychon) - Saturday, 30 June 2012, 22:45 GMT
Why does java have to use these weird focus models? :-(

Could you add some printf's to client_focus_refresh()? Dunno how well you know C, but something like:

diff --git a/objects/client.c b/objects/client.c
index a5b9d77..dab9029 100644
--- a/objects/client.c
+++ b/objects/client.c
@@ -325,8 +325,14 @@ client_focus_refresh(void)
return;
globalconf.focus.need_update = false;

+ printf("%d: ", (int) time(NULL));
if(c)
{
+ printf("Working with client '%s', nofocus: %s, take focus: %s\n",
+ c->name, c->nofocus ? "yes" : "no",
+ client_hasproto(c, WM_TAKE_FOCUS) ? "yes" : "no");
+ if(c->isbanned)
+ puts("Was banned");
/* Make sure this window is unbanned and e.g. not minimized */
client_unban(c);
/* Sets focus on window - using xcb_set_input_focus or WM_TAKE_FOCUS */
@@ -341,6 +347,7 @@ client_focus_refresh(void)
if(client_hasproto(c, WM_TAKE_FOCUS))
xwindow_takefocus(c->window);
}
+ else puts("Focusing root window");

/* If nothing has the focused or the currently focused client doesn't want
* us to focus it, this sets the focus to the root window. This makes sure
Comment by Uli Schlachter (psychon) - Friday, 06 July 2012, 11:41 GMT
Could someone test if the following commit helps? Thanks.

commit 29b09cf7da401f13335eb8f8ebb128c80454ecdd
Author: Uli Schlachter <psychon@znc.in>
Date: Fri Jul 6 13:37:58 2012 +0200

Ignore re-focusing the focused client

When something gives the input focus to the client which already has the input
focus, bad things can happen. Normally, you'd expect nothing to happen in this
case, but X11 is not that simple.

When updating the input focus and the focused client has the nofocus hint set,
we are actually taking away the focus from this client.

Hopefully this fixes  FS#973 .

Signed-off-by: Uli Schlachter <psychon@znc.in>
Comment by Anton (zhuravlik) - Friday, 06 July 2012, 17:57 GMT
Tested, verified in build:

awesome v3.4-739-g48c6c11 (Closing In)
⢠Build: Jul 6 2012 21:12:30 for x86_64 by gcc version 4.7.1 (anton@zhuravlik)
⢠Compiled against Lua 5.1.5 (running with Lua 5.1)
⢠D-Bus support: â

MATLAB menus do not lose focus, panels do not flicker, and IDEA does not hang during project creation.

Please, close  FS#1012  as duplicate.

Thank you very much for fixing this, all awt/swing users are happy now.
Comment by Moritz Kiefer (Javafant) - Friday, 27 July 2012, 08:43 GMT
This bug still occurs for me with SUMlauncher (an utility to update the game Overgrowth) if I use size_hints_honor=false.

Loading...