Keyboard issues with java inside a VM

[Olivier Médoc]

Hello,

I don't know if someone else experienced this bug, but it seems I can
not enter text in a java text field using the keyboard. Copy&paste using
the mouse middle click works, but nothing entered into the keyboard
seems to affect the content of my text field.

Any idea ? Can it be related to Qubes ?

P.S. Of course I'm running the java app inside a VM.

[Vladimir Kondakov]

You use openJDK or Oracle JDK ?

I tried both, only Oracle JDK allow enter text in a java text field.

[Olivier Médoc]

I tried with Oracle JDK, but it does not help.

The windows seems to get the focus correctly, but it does not accept any
keyboard input. I really don't have any idea; I found some possible bugs
related to Fullscreen java apps on MACOs;

[Joanna Rutkowska]

On 01/15/13 15:32, � wrote:
> On 01/15/13 12:10, Vladimir Kondakov wrote:

And did you verify this works fine on baremetal Fedora/Linux?

[Abel Luck]

Joanna Rutkowska:

I can verify this on OpenJDK 1.7.0

Running the Jitsi nightly builds [1] on vanilla Fedora 17 works fine.
Running on Qubes R1 doesn't, as it fails to accept keyboard input.

https://jitsi.org/index.php/Main/Download

[Olivier Médoc]

Can be verified with the following demo file.

I'm checking if it works in my HVM with/without the GUI agent.

[Joanna Rutkowska]

On 01/15/13 16:21, Abel Luck wrote:

Abel, can you crate a ticket for this?

[Abel Luck]

Olivier Médoc:

This is a huge test case (over 500 lines) with all sorts of extraneous
features.

Could you please pare this down to the minimal java necessary to show
that text fields aren't working?

If you do that, then I can add it to the ticket [1] and hopefully this
will get fixed sooner!

~abel


[1]" https://qubes-os.org/trac/ticket/701

[Abel Luck]

Joanna Rutkowska:

Done.
https://qubes-os.org/trac/ticket/701

[Franz]

I had the same problem and reverting to java 1.6 solved it for me.
Best
Franz

--

[Olivier Médoc]

Hi,

Please find attached two simplified test cases.

I will try reverting to java 6 for now...

Olivier

[Olivier Médoc]

Another note:

The test case doesn't works with a archlinux HVM with gui_agent running,
but it works if I disable the gui_agent.

[Joanna Rutkowska]

So, Olivier or Abel -- any of you are willing to actually debug this
issue and come up with patches? This is surely related to how our input
driver works -- it's quite an ugly and hacky code, from the early days
of Qubes development, so hopefully somebody could improve it... :)

joanna.

[Marek Marczykowski]

Currently not as hacky as before. Now there is normal xinput device for both
keyboard and mouse, AFAIK indistinguishable from any other input device. No
manual injection of xevents as was before.
But this can be some problem with focus - maybe the input goes to wrong
window. Tools like xwininfo, xev, xinput can be useful here.

--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

[Olivier Médoc]

Yes, my first guess was about focus issues. But that's a nightmare to
debug because java use lot of windows (like windows called FocusProxy
and such ...).

'xwininfo -root -all -int' help to identify the windows. I will check
xev and xinput.

[Olivier Médoc]

On 01/16/13 15:32, Olivier M�doc wrote:
> On 01/16/13 15:01, Marek Marczykowski wrote:
>> On 16.01.2013 14:55, Joanna Rutkowska wrote:

>>> On 01/16/13 14:44, Olivier M�doc wrote:

#####
## In a working environment, the Windows HIERARCHY is:
#####
8389814 (has no name): () 367x65+657+697 +657+697

16 children:
27262980 "TextInputCase": ("sun-awt-X11-XFramePeer"
"TextInputCase") 365x39+1+22 +658+719

2 children:
27262986 "FocusProxy": ("Focus-Proxy-Window" "FocusProxy")
1x1+-1+-1 +657+718

27262984 "Content window": ("sun-awt-X11-XContentWindow"
"TextInputCase") 367x65+-1+-22 +657+697

#####
## In a non working one:
#####
20971527 "TextInputCase": ("sun-awt-X11-XFramePeer"
"TextInputCase") 365x39+1167+113 +1167+113

2 children:
20971541 "FocusProxy": ("Focus-Proxy-Window" "FocusProxy")
1x1+-1+-1 +1166+112

20971539 "Content window": ("sun-awt-X11-XContentWindow"
"TextInputCase") 365x39+0+0 +1167+113

20971538 "sun-awt-X11-XIconWindow": () 16x16+0+0 +0+0

20971528 "TextInputCase": ("TextInputCase" "TextInputCase")
1x1+1+1 +1+1

################
In the working environment, the FocusProxy get the focus when I click
inside the text input, and Key event are received. Note that the
"Content window" never gets the focus.

In the non working environement, the FocusProxy does not receive any
event, and Key events are sent to the "Content window".



Now I don't know how to debug such focus issues. I don't even know who
is in charge of passing the focus from one subwindow to another one.

[Marek Marczykowski]

On 16.01.2013 16:35, Olivier Médoc wrote:

> On 01/16/13 15:32, Olivier Médoc wrote:
>> On 01/16/13 15:01, Marek Marczykowski wrote:
>>> On 16.01.2013 14:55, Joanna Rutkowska wrote:

>>>> On 01/16/13 14:44, Olivier Médoc wrote:

Why there are two TextInputCase windows? Are they also in working environment?

> In the working environment, the FocusProxy get the focus when I click inside
> the text input, and Key event are received. Note that the "Content window"
> never gets the focus.
>
> In the non working environement, the FocusProxy does not receive any event,
> and Key events are sent to the "Content window".

That's what I was afraid of...

> Now I don't know how to debug such focus issues. I don't even know who is in
> charge of passing the focus from one subwindow to another one.

The key is to find out how (and by whom) focus is given to FocusProxy.
Normally I use xtrace for it (this apparently is dead project but still
working). Call "xtrace -n -o xtrace.log app_cmdline". This produces large X11
protocol dumps (and without timestamps)...

Maybe you want to start with "qvm-prefs -s <vmname> debug on"
This will enable debug in both gui-daemon (dom0) and gui-agent (VM). In VM
logs should be in /var/log/messages (at least in case of Fedora...). Dom0 logs
are in /var/log/qubes/guid.<VM XID>.log.

Some context on gui-agent:
* Dom0 have knowledge only on main app window (formally speaking child of root
window), not subwindows. So in above case only TextInputCase window is known
to dom0. Normally it shouldn't results in problems b/c parent window should
propagate events to its children (if it properly subscribe for such
events...). Apparently this is not the case in java 7.
* GUI protocol [1] have destination window ID in all messages like mouse
motion, mouse click, keyboard event. GUI agent (VM side) does _not_ switch to
such window before delivering the event to input device - it is assumed that
appropriate MSG_FOCUS will be send earlier. Maybe something is wrong here if
java change focus itself...
* There is something about input focus in XEMBED protocol [2]. Perhaps
something is missing in gui-agent?
* Some useful line numbers in gui-agent/vmside.c [3]:
- handling keyboard events: 917 (handle_keypress function)
- handling mouse events: 1009 (handle_button) and 1053 (handle_motion)
- mouse enter/leave notify: 1099 (handle_crossing)
- focus in/out events: 1156 (handle_focus)
- handling XEMBED requests (embedding tray icon window) - not really related
but maybe will give some hints: 646 (process_xevent_message func)

Note that handle_focus in case of FocusIn also raises the window.

[1] http://www.qubes-os.org/trac/wiki/GUIdocs
[2] http://standards.freedesktop.org/xembed-spec/xembed-spec-0.5.html#id2925676
[3]
http://git.qubes-os.org/?p=marmarek/gui.git;a=blob;f=gui-agent/vmside.c;h=f03dd7c192c48d1d40a4a233795df2e7da930033;hb=HEAD

[Olivier Médoc]

Analysing while printing Window events inside the java app shows that the
FOCUS_LOST
WINDOW_LOST_FOCUS
WINDOW_DEACTIVATED
are received immediatly after the window is started and gained focus, which is not the case in a working environment (the app is focused and keep the focus until I click somewhere else).

------------------------------------------------------------------------
Maybe, this:
http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/awt.html

On Solaris OS and Linux, XToolkit uses a focus model that allows AWT to manage focus itself. With this model the window manager does not directly set input focus on a top-level window, but instead it sends only the WM_TAKE_FOCUS client message to indicate that focus should be set. AWT then explicitly sets focus on the top-level window if it is allowed.

Note that X server and some window managers may nevertheless send focus events to a window. However all such events are discarded by AWT.

AWT does not generate the hierarchical chains of focus events when a component inside a top-level gains focus. Moreover, the native window mapped to the component itself does not get any native focus event. On the Solaris OS and Linux platforms, as well as on the Windows platform, AWT uses the focus proxy mechanism. Therefore, focus on the component is set by synthesizing a focus event, whereas the invisible focus proxy has native focus.

A native window that is mapped to a Window object (not a Frame or Dialog object) has the override-redirect flag set. Thus the window manager does not notify the window about focus change. Focus is requested on the window only in response to a mouse click. This window will not receive native focus events at all. Therefore, you can trace only FocusIn or FocusOut events on a frame or dialog. Since the major processing of focus occurs at the Java level, debugging focus with XToolkit is simpler than with WToolkit.

---------------------------------------------------
Another test using openjdk 1.6 (it seems to work with openjdk):

     23068679 "TextInputCase": ("sun-awt-X11-XFramePeer" "TextInputCase")  365x39+1231+722  +1231+722
        2 children:
        23068693 "FocusProxy": ("Focus-Proxy-Window" "FocusProxy")  1x1+-1+-1  +1230+721
        23068691 "Content window": ("sun-awt-X11-XContentWindow" "TextInputCase")  365x39+0+0  +1231+722
     23068690 "sun-awt-X11-XIconWindow": ()  16x16+0+0  +0+0
     23068680 "TextInputCase": ("TextInputCase" "TextInputCase")  1x1+1+1  +1+1


$ xev -id      23068679
# When starting the window

EnterNotify event, serial 13, synthetic NO, window 0x1600007,
    root 0x131, subw 0x1600013, time 14082785, (173,0), root:(1404,722),
    mode NotifyNormal, detail NotifyNonlinearVirtual, same_screen YES,
    focus NO, state 16

KeymapNotify event, serial 13, synthetic NO, window 0x0,
    keys:  4294967177 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0  
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0  

# On click:
LeaveNotify event, serial 13, synthetic NO, window 0x1600007,
    root 0x131, subw 0x1600013, time 14086761, (171,18), root:(1402,740),
    mode NotifyNormal, detail NotifyNonlinearVirtual, same_screen YES,
    focus NO, state 16

ConfigureNotify event, serial 13, synthetic NO, window 0x1600007,
    event 0x1600007, window 0x1600007, (1231,722), width 365, height 39,
    border_width 0, above 0x200002, override NO

EnterNotify event, serial 13, synthetic NO, window 0x1600007,
    root 0x131, subw 0x1600013, time 14086765, (171,18), root:(1402,740),
    mode NotifyNormal, detail NotifyNonlinearVirtual, same_screen YES,
    focus NO, state 16

KeymapNotify event, serial 13, synthetic NO, window 0x0,
    keys:  4294967236 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0  
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0  

FocusIn event, serial 13, synthetic NO, window 0x1600007,
    mode NotifyNormal, detail NotifyNonlinear

KeymapNotify event, serial 13, synthetic NO, window 0x0,
    keys:  4294967194 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0  
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0  

FocusOut event, serial 13, synthetic NO, window 0x1600007,
    mode NotifyNormal, detail NotifyInferior


$ xev -id      23068693
# When starting the window
no event

# On Click

FocusIn event, serial 13, synthetic NO, window 0x1600015,
    mode NotifyNormal, detail NotifyAncestor

KeymapNotify event, serial 13, synthetic NO, window 0x0,
    keys:  4294967177 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0  
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0  


---------------------------------------------------
Actually, I'm starting to think that it is a java bug... Why this difference between java 6 and java 7 knowing that the Focus proxy mecanism already exists in java 6 ?

[Marek Marczykowski]

> A *native window that is mapped to a Window object* (not a Frame or Dialog
> object) *has the override-redirect flag* *set*. Thus the window manager does

WM_TAKE_FOCUS looks like right way. It isn't supported by gui-agent so java
shouldn't rely on it. Anyway the protocol (part of xembed protocol) seems to
be very simple to implement (just send WM_PROCOTOLS with WM_TAKE_FOCUS and
timestamp in handle_focus). You can do simple test by sending such message
manually (don't know if it is possible without writing simple C program). I
will look at it sometime later today/tomorrow.

[Marek Marczykowski]

(...)

>> Analysing while printing Window events inside the java app shows that the
>> FOCUS_LOST
>> WINDOW_LOST_FOCUS
>> WINDOW_DEACTIVATED
>> are received immediatly after the window is started and gained focus, which is
>> not the case in a working environment (the app is focused and keep the focus
>> until I click somewhere else).
>>
>> ------------------------------------------------------------------------
>> Maybe, this:
>> http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/awt.html

(...)

> WM_TAKE_FOCUS looks like right way. It isn't supported by gui-agent so java
> shouldn't rely on it. Anyway the protocol (part of xembed protocol) seems to
> be very simple to implement (just send WM_PROCOTOLS with WM_TAKE_FOCUS and
> timestamp in handle_focus). You can do simple test by sending such message
> manually (don't know if it is possible without writing simple C program). I
> will look at it sometime later today/tomorrow.

Ok, it looks exactly like one of xmonad issue [1]. There is detailed
description, links to specification, test program etc. Indeed gui-agent do not
follow ICCCM spec here. There is also patch attached, but... xmonad is written
in haskell so pretty useless here.
Do you want to send patch for it?

[1] http://code.google.com/p/xmonad/issues/detail?id=177

[Olivier Médoc]

Got it !!

The key point was to check if the Window set something called InputHint:

"Passive and Locally Active clients set the input field of WM_HINTS to
True , which indicates that they require window manager assistance in
acquiring the input focus"

Then I launch TAKE_FOCUS. I didn't generated a real timestamp and reused
CurrentTimestamp which is apparently not recommanded.

I didn't touched to FocusOut events as it is apparently not necessary.

Hope I didn't broke something...

[Marek Marczykowski]

Same as in xmonad patch, so someone have tested it :)

> I didn't touched to FocusOut events as it is apparently not necessary.
>
> Hope I didn't broke something...

Comments about the patch inline.

>
> --
>
>
>
> 0001-gui-agent-Implementation-of-WM_TAKE_FOCUS.patch
>
>
> From 774b76b37bb30994e1b2efdf5f4b9fbe39bbcfbe Mon Sep 17 00:00:00 2001
> From: Olivier Medoc <o_m...@yahoo.fr>
> Date: Fri, 18 Jan 2013 17:05:27 +0100
> Subject: [PATCH] gui-agent: Implementation of WM_TAKE_FOCUS
>
> Only for FocusIn events : need to retrieve and store the InputHint for each window in order to know if the window want to receive InputFocus events. Send WM_TAKE_FOCUS to all window anyway.
> ---
> gui-agent/vmside.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/gui-agent/vmside.c b/gui-agent/vmside.c
> index f03dd7c..a0839ff 100644
> --- a/gui-agent/vmside.c
> +++ b/gui-agent/vmside.c
> @@ -64,12 +64,14 @@ struct _global_handles {
> Atom wm_state; /* Atom: _NET_WM_STATE */
> Atom wm_state_fullscreen; /* Atom: _NET_WM_STATE_FULLSCREEN */
> Atom wm_state_demands_attention; /* Atom: _NET_WM_STATE_DEMANDS_ATTENTION */
> + Atom wm_take_focus; /* Atom: WM_TAKE_FOCUS */
> int xserver_fd;
> Window stub_win; /* window for clipboard operations and to simulate LeaveNotify events */
> unsigned char *clipboard_data;
> unsigned int clipboard_data_len;
> int log_level;
> int sync_all_modifiers;
> + int input_hint; /* the window should get input focus - False=Never */

This should be per-window data, not global one. Struct _global_handles as name
suggests is common for all windows.
Per-window data can be stored in "struct window_data" attached as "data" to
window_list. Note that currently data field is allocated only on docked
windows (check process_xevent_message function) - now it looks that every
window will need such struct (which isn't bad in any way).

> };
>
> struct window_data {
> @@ -273,6 +275,32 @@ void send_wmname(Ghandles * g, XID window)
> write_message(hdr, msg);
> }
>
> +/* Retrieve the 'real' WMHints.
> + We don't forward the info to dom0 as we only need InputHint and dom0 doesn't care about it
> +*/
> +void send_wmhints2(Ghandles * g, XID window)

If function isn't intended to send anything out, it shouldn't be called
"send_wmhints32", better "retrieve_wmhints32".

> +{
> + XWMHints *wm_hints;
> +
> + if (!(wm_hints = XGetWMHints(g->display, window))) {
> + fprintf(stderr, "error reading WM_HINTS\n");
> + return;
> + }
> +
> + if (wm_hints->flags & InputHint) {
> + g->input_hint = wm_hints->input;
> +
> + if (g->log_level > 1)
> + fprintf(stderr, "Received input hint 0x%x for windows 0x%x\n", g->input_hint, (int)window);
> + } else {
> + // Default value
> + if (g->log_level > 1)
> + fprintf(stderr, "Received WMHints without input hint set for window 0x%x\n", (int)window);
> + g->input_hint = True;
> + }
> + XFree(wm_hints);
> +}
> +
> void send_wmhints(Ghandles * g, XID window)
> {
> struct msghdr hdr;
> @@ -302,6 +330,7 @@ void send_wmhints(Ghandles * g, XID window)
> write_message(hdr, msg);
> }
>
> +
> static inline uint32_t flags_from_atom(Ghandles * g, Atom a) {
> if (a == g->wm_state_fullscreen)
> return WINDOW_FLAG_FULLSCREEN;
> @@ -619,6 +648,9 @@ void process_xevent_property(Ghandles * g, XID window, XPropertyEvent * ev)
> else if (ev->atom ==
> XInternAtom(g->display, "WM_NORMAL_HINTS", False))
> send_wmhints(g, window);
> + else if (ev->atom ==
> + XInternAtom(g->display, "WM_HINTS", False))
> + send_wmhints2(g,window);
> else if (ev->atom == g->xembed_info) {
> struct genlist *l = list_lookup(windows_list, window);
> Atom act_type;
> @@ -912,6 +944,7 @@ void mkghandles(Ghandles * g)
> g->wm_state = XInternAtom(g->display, "_NET_WM_STATE", False);
> g->wm_state_fullscreen = XInternAtom(g->display, "_NET_WM_STATE_FULLSCREEN", False);
> g->wm_state_demands_attention = XInternAtom(g->display, "_NET_WM_STATE_DEMANDS_ATTENTION", False);
> + g->wm_take_focus = XInternAtom(g->display, "WM_TAKE_FOCUS", False);
> }
>
> void handle_keypress(Ghandles * g, XID winid)
> @@ -1153,6 +1186,25 @@ void handle_crossing(Ghandles * g, XID winid)
>
> }
>
> +void take_focus(Ghandles * g, XID winid)
> +{
> + // Send
> + XClientMessageEvent ev;
> + memset(&ev, 0, sizeof(ev));
> + ev.type = ClientMessage;
> + ev.display = g->display;
> + ev.window = winid;
> + ev.format = 32;
> + ev.message_type = g->wmProtocols;
> + ev.data.l[0] = g->wm_take_focus;
> + ev.data.l[1] = CurrentTime;
> + XSendEvent(ev.display, ev.window, TRUE, 0, (XEvent *) & ev);
> + if (g->log_level > 0)
> + fprintf(stderr, "wm_TAKE_FOCUS sent for 0x%x\n",
> + (int) winid);
> +
> +}
> +
> void handle_focus(Ghandles * g, XID winid)
> {
> struct msg_focus key;
> @@ -1173,19 +1225,31 @@ void handle_focus(Ghandles * g, XID winid)
> #endif
> if (key.type == FocusIn
> && (key.mode == NotifyNormal || key.mode == NotifyUngrab)) {
> +
> XRaiseWindow(g->display, winid);
> - XSetInputFocus(g->display, winid, RevertToParent,
> +
> + // Give input focus only to window that set the input hint
> + if (g->input_hint)

Same as earlier - g->input_hint is global, not local to the window.

> + XSetInputFocus(g->display, winid, RevertToParent,
> CurrentTime);
> +
> + // TODO: do not send take focus if the window doesn't support it ?

Not sure how about the case when window have no WM_HINTS propery at all.
Anyway support for WM_TAKE_FOCUS should announced by window in WM_PROTOCOLS
property (maybe also should be monitoried in process_xevent_property?). IMO
fallback should be XSetInputFocus.

> + take_focus(g, winid);
> +
> if (g->log_level > 1)
> fprintf(stderr, "0x%x raised\n", (int) winid);
> } else if (key.type == FocusOut
> && (key.mode == NotifyNormal
> || key.mode == NotifyUngrab)) {
> +
> XSetInputFocus(g->display, None, RevertToParent,
> CurrentTime);
> +
> + //take_focus();

Souldn't be needed here, even as comment...

> if (g->log_level > 1)
> fprintf(stderr, "0x%x lost focus\n", (int) winid);
> }
> +
> }
>
> int bitset(unsigned char *keys, int num)
> -- 1.7.11.7

[Olivier Médoc]

OK, thanks for your help again, I only start to understand how all these
things works :P

I allocated window_data on Window creation.

In a second patch, I implemented retrieve_protocols as you suggested.

Note that I still don't use InputFocus as a fallback if input_hint is
set to false and take_focus is not supported by the window. I'm checking
if it is necessary from the debug logs. This would be a strange window
behavior anyway, but I can still change if (input_hint) to if
(input_hint && !use_take_focus) or print a WARNING to stderr.

[Marek Marczykowski]

Now looks much better. But can you merge patches 1 and 2? Now patch 2 revert
some changes made by patch 1...
Perhaps separate rename send_wmhints->send_wmnormalhints to individual patch
(before other changes). "git rebase" is your friend here.

[Olivier Médoc]

Like this ?

[Marek Marczykowski]

Exactly :)
Applied, thanks!

[Olivier Médoc]

Le 15/01/2013 12:10, Vladimir Kondakov a �crit :

In fact since my last patch, it seems that the network manager tray icon
does not appears anymore... Or maybe this is related to the new
qubes-session system (using rpc call) ...

[Marek Marczykowski]

On 26.01.2013 13:32, Olivier Médoc wrote:
> Le 15/01/2013 12:10, Vladimir Kondakov a écrit :

>> On 15.01.2013 15:07, Olivier Médoc wrote:
>>> Hello,
>>>
>>> I don't know if someone else experienced this bug, but it seems I can
>>> not enter text in a java text field using the keyboard. Copy&paste using
>>> the mouse middle click works, but nothing entered into the keyboard
>>> seems to affect the content of my text field.
>>>
>>> Any idea ? Can it be related to Qubes ?
>>>
>>> P.S. Of course I'm running the java app inside a VM.
>>>
>> You use openJDK or Oracle JDK ?
>>
>> I tried both, only Oracle JDK allow enter text in a java text field.
>>
> In fact since my last patch, it seems that the network manager tray icon does
> not appears anymore... Or maybe this is related to the new qubes-session
> system (using rpc call) ...

The qubes-session is more likely (but it works for me). Does it work when you
start nm-applet manually?

[Olivier Médoc]

No, it doesn't work. It just say: **Message: applet removed from the
notification area and it wait for something.

In the logs, I see: open(/etc/NetworkManager/system-connections) failed:
too many levels of symbolic links (because of a bug in
network-manager-prepare-conf-dir).

Before starting a terminal in netvm, if I run qvm-run --pass-io --nogui
netvm 'ls /tmp', I see both qubes-session-env and qubes-session-waiter.

Also qubes-session is running, Xorg, nm-applet and applet.py are also
running. I attached qubes_gui logs (start at 14:40:53).

[Olivier Médoc]

Le 26/01/2013 13:32, Olivier M�doc a �crit :

Ok, now that I reinstalled the old gui-agent version, I can confirm that
it comes from my gui-agent patches. I have now to find what is going wrong.

[Olivier Médoc]

Le 28/01/2013 16:26, Olivier M�doc a �crit :

Ok, I think the problem is that SKIP_NONMANAGED_WINDOW is defined like this:

#define SKIP_NONMANAGED_WINDOW if (!list_lookup(windows_list, window))
return

So from my patch, all created windows are considered as managed because
I initialize the windows_list whatever the case.

[Olivier Médoc]

Ok, I found the culprit. It is a stupid invalid 'if' statement I created
:(. I also fixed a potential issue (using '1' instead of True), and
reapplied your patch for configure.ac, with the right MACRO definition.

[Marek Marczykowski]

Applied.