FVWM: Mouse click problem with Corebird plus my FVWM configuration

Post by Chris Siebenmann
https://corebird.baedert.org/
In attempting to use the current version on Fedora 25, I have uncovered
a weird oddity where I cannot click links with the left mouse button when
using my FVWM configuration. Corebird recognizes that I have clicked and
will do things like select text, but does not see it as quite whatever
is needed to make it see things as a click that activates the link. A long
https://bugzilla.redhat.com/show_bug.cgi?id=1425611

My guess, bad hardware.

When you click a mouse it should generate 2 X11 events:

ButtonPress
ButtonRelease

This symptom in the bug report:

I tried keynav and discovered some quite interesting results. First, the
keynav worked as you described. And second, what I hadn't noticed
before, is that when I click on a link (or try to), what happens
visually is that a dotted gray box appears around the link, just as in
keynav, and if I hit return the link is activated.

makes me suspicious that you are only seeing one of the events
or some other event oddity.

In general Fvwm does not interfere with mouse clicks unless you tell
it to. If you still think Fvwm is involved remove your mouse 0
and 1 bindings and test. You have 12 of them.

--
Dan Espen

Chris Siebenmann

2017-03-01 00:54:03 UTC

My guess, bad hardware.
ButtonPress
ButtonRelease

I've just used xev to confirm that I see ButtonPress and ButtonRelease
events. However, what I have discovered is that I see additional events
with my FVWM configuration. Immediately before a ButtonPress, I also get:

ButtonRelease event, serial 33, synthetic NO, window 0x600001,
root 0x26d, subw 0x0, time 672491078, (62,72), root:(856,280),
state 0x100, button 1, same_screen YES

LeaveNotify event, serial 33, synthetic NO, window 0x600001,
root 0x26d, subw 0x0, time 672491437, (62,72), root:(856,280),
mode NotifyGrab, detail NotifyAncestor, same_screen YES,
focus YES, state 256

EnterNotify event, serial 33, synthetic NO, window 0x600001,
root 0x26d, subw 0x0, time 672491437, (62,72), root:(856,280),
mode NotifyUngrab, detail NotifyAncestor, same_screen YES,
focus YES, state 256

KeymapNotify event, serial 33, synthetic NO, window 0x0,
keys: 109 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

ButtonPress event, serial 33, synthetic NO, window 0x600001,
root 0x26d, subw 0x0, time 672491437, (62,72), root:(856,280),
state 0x0, button 1, same_screen YES

(This is in xev, clicking and releasing and re-clicking and re-releasing,
with no mouse movement at all.)

Doing the same xev test with 'fvwm -f /dev/null' sees only the expected
ButtonPress/ButtonRelease events.

Post by Dan Espen
I tried keynav and discovered some quite interesting results. First, the
keynav worked as you described. And second, what I hadn't noticed
before, is that when I click on a link (or try to), what happens
visually is that a dotted gray box appears around the link, just as in
keynav, and if I hit return the link is activated.
makes me suspicious that you are only seeing one of the events
or some other event oddity.
In general Fvwm does not interfere with mouse clicks unless you tell
it to. If you still think Fvwm is involved remove your mouse 0
and 1 bindings and test. You have 12 of them.

If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
file (from the URL) *except* either:

Mouse 1 A MS Iconify
or
Mouse 1 A M Raise

then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
in xev and clicking on links no longer works in Corebird.

If I comment out those two bindings but leave everything else commented
in, I don't see any problems.

Unfortunately I use Shift-Meta-1 to iconify very frequently, so not having
this binding would be very painful. It also doesn't cause problems in
other applications; everything else I use (Firefox, Liferea, Choqok,
and basically every other GUI program I can think of) is fine with
this binding.

- cks

Dan Espen

2017-03-01 01:20:17 UTC

My guess, bad hardware.
ButtonPress
ButtonRelease

I've just used xev to confirm that I see ButtonPress and ButtonRelease
events. However, what I have discovered is that I see additional events
ButtonRelease event, serial 33, synthetic NO, window 0x600001,
root 0x26d, subw 0x0, time 672491078, (62,72), root:(856,280),
state 0x100, button 1, same_screen YES

The first event you see SHOULD be ButtonPress.
Are you sure there is a release before the press?
If so, bad hardware.

(Still guessing.)

Post by Chris Siebenmann
If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
Mouse 1 A MS Iconify
or
Mouse 1 A M Raise
then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
in xev and clicking on links no longer works in Corebird.
If I comment out those two bindings but leave everything else commented
in, I don't see any problems.

Try using another modifier besides Meta.
X11 looks for a KeyPress event to know Meta is on and KeyRelease
to know it is off. Use xev to verify that pressing Meta only produces
a press followed by a release.

--
Dan Espen

Chris Siebenmann

2017-03-01 01:42:38 UTC

Post by Dan Espen
ButtonPress
ButtonRelease

The first event you see SHOULD be ButtonPress.
Are you sure there is a release before the press?
If so, bad hardware.
(Still guessing.)

Sorry, I failed to be clear in what I wrote (my fault). The sequence
of events for a button press and release is:

LeaveNotify
EnterNotify
KeymapNotify
ButtonPress
ButtonRelease

I mentioned the preceeding ButtonRelease to show that there was nothing
in between this sequence, and I accidentally left out the ButtonRelease
in my transcript.

The LeaveNotify, EnterNotify, and KeymapNotify happen in a burst
immediately before the ButtonPress (and all of them happen as I press the
button down). The ButtonRelease happens after I let up the button, so I
can create as much delay as I want between ButtonPress and ButtonRelease
by continuing to hold it down.

I've verified that any modifier appears to do this, and that all of
my modifiers produce only KeyPress then KeyRelease events when pressed
down and then released by themselves.

(And, to be clear, I'm not holding down any modifiers when doing these
button clicks.)

Also, it occurred to me that I have 'A' bindings for Mouse 2 and Mouse
3 as well. Testing with xev shows that both of these mouse buttons also
produce the same burst of LeaveNotify, EnterNotify, and KeymapNotify
immediately before a button-down event in xev. This is exactly what
I'd expect if there is something in how fvwm processes these 'Anywhere'
bindings that is causing these events to be generated.

- cks

Dominik Vogt

2017-03-01 02:17:12 UTC

Post by Chris Siebenmann
If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
Mouse 1 A MS Iconify
or
Mouse 1 A M Raise

Try

mouse 1 tsifw ...

instead. Limit the context a binding applies to to what is
needed. It's inefficient and interferes with other programs'
bindings. Or do you really iconify windows by clicking on the
root window?

Post by Chris Siebenmann
then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
in xev

Forget about these; that's just how X works.

Ciao

Dominik ^_^ ^_^

--
Dominik Vogt

Chris Siebenmann

2017-03-01 14:43:58 UTC

Post by Chris Siebenmann
If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
Mouse 1 A MS Iconify
or
Mouse 1 A M Raise

Try
mouse 1 tsifw ...
instead. Limit the context a binding applies to to what is
needed. It's inefficient and interferes with other programs'
bindings. Or do you really iconify windows by clicking on the
root window?

I've now tested and the problem happens with just:

Mouse 1 W MS Iconify

... which is about the minimal binding, since I really do want to
iconify windows with meta-shift-1 anywhere inside them.

Post by Chris Siebenmann
then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
in xev

Forget about these; that's just how X works.

Is it possible that some part of GTK+ doesn't like this sequence
of events and ignores ButtonPress/ButtonRelease as a result? It is
relatively striking to me how correlated things are here.

- cks

Dominik Vogt

2017-03-01 18:02:55 UTC

Post by Chris Siebenmann
If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
Mouse 1 A MS Iconify
or
Mouse 1 A M Raise

Try
mouse 1 tsifw ...
instead. Limit the context a binding applies to to what is
needed. It's inefficient and interferes with other programs'
bindings. Or do you really iconify windows by clicking on the
root window?

Mouse 1 W MS Iconify
... which is about the minimal binding, since I really do want to
iconify windows with meta-shift-1 anywhere inside them.

Referring to the other message, I disagree with the analysis
there. Fvwm grabs only the modifier combinations on windows that
it needs, i.e. the ones that are present in the binding. See
libs/Bindings.c:GrabWindowButton(). Unless you have you have
something like

IgnoreModifiers MS

The only other reason fvwm grabs a button is for focus handling in
focus.c:__focus_grab_one_button(). The only possible reason I
could think of is that the application does not accept focus so
that grab never gets removed. Have you tried

Style * Lenience

as Dan suggested?

For further debugging, does the problem go away with

style * clicktofocus, clicktofocusraises, ClickToFocusPassesClick

Unless I have a simple test application and a configuration that
exhibits that behaviour I cannot do much about it. Would you be
able to fvwm in Xnest and debug through
events.c:__handle_bpress_on_managed() to see what actually
happens?

Post by Chris Siebenmann
then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
in xev

Forget about these; that's just how X works.

Is it possible that some part of GTK+ doesn't like this sequence
of events and ignores ButtonPress/ButtonRelease as a result?

No.

Post by Chris Siebenmann
It is relatively striking to me how correlated things are here.

These events are generated as a side effect of button presses by
design of the X protocol. An application that cannot deal with
them is broken.

Ciao

Dominik ^_^ ^_^

--
Dominik Vogt

Dominik Vogt

2017-03-01 18:12:23 UTC

Post by Chris Siebenmann
If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
Mouse 1 A MS Iconify
or
Mouse 1 A M Raise

Try
mouse 1 tsifw ...
instead. Limit the context a binding applies to to what is
needed. It's inefficient and interferes with other programs'
bindings. Or do you really iconify windows by clicking on the
root window?

Mouse 1 W MS Iconify
... which is about the minimal binding, since I really do want to
iconify windows with meta-shift-1 anywhere inside them.

Referring to the other message, I disagree with the analysis
there. Fvwm grabs only the modifier combinations on windows that
it needs, i.e. the ones that are present in the binding. See
libs/Bindings.c:GrabWindowButton(). Unless you have you have
something like
IgnoreModifiers MS
The only other reason fvwm grabs a button is for focus handling in
focus.c:__focus_grab_one_button(). The only possible reason I
could think of is that the application does not accept focus so
that grab never gets removed. Have you tried
Style * Lenience
as Dan suggested?
For further debugging, does the problem go away with
style * clicktofocus, clicktofocusraises, ClickToFocusPassesClick
Unless I have a simple test application and a configuration that
exhibits that behaviour I cannot do much about it. Would you be
able to fvwm in Xnest and debug through
events.c:__handle_bpress_on_managed() to see what actually
happens?

By the way, have you tried to get the application developers'
opinion? From the xev output is seems that the button events are
reported to the program, so why doesn't it react to them?

Ciao

Dominik ^_^ ^_^

--
Dominik Vogt

Chris Siebenmann

2017-03-01 15:43:56 UTC

Post by Chris Siebenmann
then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
in xev

Forget about these; that's just how X works.

I dusted off old memories about the patches that I'm carrying in my
home fvwm binary and not my work one, and I think that this has come
up before and had a patch proposed before. If I'm right, see this
fvwm-workers discussion from early September 2014:

https://www.mail-archive.com/fvwm-***@fvwm.org/msg03528.html

This change was reverted here:
https://www.mail-archive.com/fvwm-***@fvwm.org/msg03596.html

apparently because of this issue:
https://www.mail-archive.com/fvwm-***@fvwm.org/msg03593.html

This came out of my May 2013 report of a very similar issue with
Darktable, which is also a GTK+ application. At the time I wound up
localizing it to those same Mouse 1 'A' bindings I have (in email between
me and Thomas Adam, not captured in the mailing list archives). The
initial fvwm thread about it is here:

http://www.mail-archive.com/***@fvwm.org/msg02464.html

This is apparently also a Debian bug report with somewhat more
specific details about the GTK+ bits with problems, from 2011:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642151

I've built a version of git tip fvwm with the patch from Thomas
Adam and it appears to fix this issue for me (although presumably
the patch still has the issue that caused it to be reverted).

- cks

Chris Siebenmann

2017-03-01 18:36:52 UTC

Post by Dominik Vogt
The only other reason fvwm grabs a button is for focus handling in
focus.c:__focus_grab_one_button(). The only possible reason I
could think of is that the application does not accept focus so
that grab never gets removed. Have you tried
Style * Lenience
as Dan suggested?
For further debugging, does the problem go away with
style * clicktofocus, clicktofocusraises, ClickToFocusPassesClick

With both 'Style *' settings (and with my usual 'SloppyFocus' setting
commented out), the problem is still there. I also tested with just
'Style * Lenience' and the problem is also still there.

Post by Dominik Vogt
Unless I have a simple test application and a configuration
that exhibits that behaviour I cannot do much about it.
Would you be able to fvwm in Xnest and debug through
events.c:__handle_bpress_on_managed() to see what actually happens?

The flow appears to be:
__handle_bpress_on_managed()
-> __handle_focus_raise_click()
-> __check_click_to_focus_or_raise()
returning f.do_focus and f.do_raise both 0

f.do_forbid_function is 0, so we check bindings.
-> __handle_bpress_action() which returns false
if (IS_SCHEDULED_FOR_RAISE(fw)) is false; we skip that block
f.do_swallow_click is false, so we call:
XAllowEvents(dpy, ReplayPointer, CurrentTime)
XFlush(dpy)
... and return.

(Let me know if you want more detail somewhere here and I can rerun
my gdb tracing and/or add printfs appropriately.)

Fortunately there is a simple reproduction program mentioned in the
Debian bug, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642151
that comes from the Ubuntu compiz bug report. For convenience, I've
put it up as its own (shorter) URL:
https://www.cs.toronto.edu/~cks/tmp/fvwm/link.py
and my fvwmrc:
https://www.cs.toronto.edu/~cks/tmp/fvwm/fvwmrc-2.5

If you have the Python GTK bindings (so that link.py runs at all), it
puts up a label box with an underlined link. If you click on the link,
it's supposed to print something like:

link <gtk.Label object at 0x7f64ef58dd70 (GtkLabel at 0x55f69d5c4d40)> http://gtk.org

In a configuration with a Mouse 1 binding that includes the Window
context (so W or A), the link can't be activated by clicking mouse-1
and link.py prints nothing. You can however get it to print something
by clicking on the link and then hitting Return to activate the link
through the keyboard.

- cks

Dominik Vogt

2017-03-01 19:36:58 UTC

Post by Chris Siebenmann
(Let me know if you want more detail somewhere here and I can rerun
my gdb tracing and/or add printfs appropriately.)
Fortunately there is a simple reproduction program mentioned in the
Debian bug, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642151
that comes from the Ubuntu compiz bug report. For convenience, I've
https://www.cs.toronto.edu/~cks/tmp/fvwm/link.py
https://www.cs.toronto.edu/~cks/tmp/fvwm/fvwmrc-2.5
If you have the Python GTK bindings (so that link.py runs at all), it
puts up a label box with an underlined link.

No idea, but the window with the "link" appears.

Post by Chris Siebenmann
link <gtk.Label object at 0x7f64ef58dd70 (GtkLabel at 0x55f69d5c4d40)> http://gtk.org
In a configuration with a Mouse 1 binding that includes the Window
context (so W or A), the link can't be activated by clicking mouse-1
and link.py prints nothing. You can however get it to print something
by clicking on the link and then hitting Return to activate the link
through the keyboard.

Okay, this is reproduceable. I know nothing about python or Gtk+,
so this may be easy, but here, when you click on the window, xev
prints no ButtonPress or ButtonRelease events at all neither with
nor without the binding. Is there a way so that the program
prints all events it sees?

The "A" context bindings actually do cause grabbing the button
with any modifiers globally (in order to cut down the total number
of grabs, I think). It's just a global mask of buttons to grab
globally, and most applications don't care about it. There may be
some change in the sequence of events the application gets, or
maybe the timestamps, but its hard to say without actually seeing
the events.

Ciao

Dominik ^_^ ^_^

--
Dominik Vogt

Dominik Vogt

2017-03-01 19:45:36 UTC

No idea, but the window with the "link" appears.

Okay, this is reproduceable. I know nothing about python or Gtk+,
so this may be easy, but here, when you click on the window, xev
prints no ButtonPress or ButtonRelease events at all neither with
nor without the binding. Is there a way so that the program
prints all events it sees?
The "A" context bindings actually do cause grabbing the button
with any modifiers globally (in order to cut down the total number
of grabs, I think). It's just a global mask of buttons to grab
globally, and most applications don't care about it. There may be
some change in the sequence of events the application gets, or
maybe the timestamps, but its hard to say without actually seeing
the events.

There's another strange symptom that seems to point to a button
handling problem in the library, as it occurs even without such a
"trigger" binding. Without a "mouse 3 a ..." binding:

* Move the pointer over "link". The test gets highlighted in
white.
* Push button 3. The text gets a dark grey background, and a
popup menu opens.
* Hit the "Escape" key to close the popup. The text background
is light grey now.
* Do not move the pointer now; otherwise the problem goes away.
* Clicking with button 3 again does nothing. Pressing the
"Return" key still works.

It seems the library gets confused about the window's state.

Ciao

Dominik ^_^ ^_^

--
Dominik Vogt

Dominik Vogt

2017-03-01 19:48:07 UTC

No idea, but the window with the "link" appears.

Okay, this is reproduceable. I know nothing about python or Gtk+,
so this may be easy, but here, when you click on the window, xev
prints no ButtonPress or ButtonRelease events at all neither with
nor without the binding. Is there a way so that the program
prints all events it sees?
The "A" context bindings actually do cause grabbing the button
with any modifiers globally (in order to cut down the total number
of grabs, I think). It's just a global mask of buttons to grab
globally, and most applications don't care about it. There may be
some change in the sequence of events the application gets, or
maybe the timestamps, but its hard to say without actually seeing
the events.

There's another strange symptom that seems to point to a button
handling problem in the library, as it occurs even without such a
* Move the pointer over "link". The test gets highlighted in
white.
* Push button 3. The text gets a dark grey background, and a
popup menu opens.
* Hit the "Escape" key to close the popup. The text background
is light grey now.
* Do not move the pointer now; otherwise the problem goes away.
* Clicking with button 3 again does nothing. Pressing the
"Return" key still works.
It seems the library gets confused about the window's state.

Note: This bug is present even in the complete absence of a
window manager, when the program runs on a plain, unmanaged X
screen.

Ciao

Dominik ^_^ ^_^

--
Dominik Vogt

Chris Siebenmann

2017-03-01 18:41:38 UTC

By the way, have you tried to get the application developers' opinion?
From the xev output is seems that the button events are reported to
the program, so why doesn't it react to them?

This appears to be something that's happening in the guts of the
GTK+ library, not in application specific code. As far as I know from
looking at the source code, Corebird (and Darktable) are delegating all
rendering and event handling to GTK+'s HTML-capable widgets and only
responding to activities that those library widgets report back.

This may be a GTK+ issue, but even if the GTK+ people accept this as a
bug (and they may argue very much against it, since all of this works
in their officially approved environments and other window manager
environments and so on) it's not going to get fixed any time soon in
widely deployed systems, many of which will be running current (or old)
GTK+ versions for years to come.

- cks

Chris Siebenmann

2017-03-01 20:10:48 UTC

I don't know if there's a way to get GTK to do that, but I can
use the blunt hammer of xtrace here:
https://xtrace.alioth.debian.org/

Based on this, the link.py script is seeing LeaveNotify and EnterNotify
events before the ButtonPress event. The initial numbers here are
relative time since program start in seconds, and I left the program
idle for several seconds to make sure things would stand out (and indeed
they do):

5.042 000:>:0206: Event LeaveNotify(8) detail=Ancestor(0x00) mode=Grab(0x01) flags=same-screen time=0x05ee50ba root=0x0000026d event=0x00600003 child=None(0x00000000) root-x=702 root-y=319 event-x=128 event-y=102 state=Button1

[link.py wakes up and wakes a ton of requests and RENDER-Requests]

5.043 000:>:0235: Event UnmapNotify(18) event=0x00600043 window=0x00600043 from-configure=false(0x00)
5.045 000:>:0235: Event VisibilityNotify(15) window=0x00600003 state=Unobscured(0x00)
5.046 000:>:0235: Event Expose(12) window=0x00600003 x=145 y=117 width=38 height=1 count=0x0004
5.046 000:>:0235: Event Expose(12) window=0x00600003 x=144 y=118 width=40 height=1 count=0x0003
5.046 000:>:0235: Event Expose(12) window=0x00600003 x=143 y=119 width=42 height=33 count=0x0002
5.046 000:>:0235: Event Expose(12) window=0x00600003 x=144 y=152 width=40 height=1 count=0x0001
5.046 000:>:0235: Event Expose(12) window=0x00600003 x=145 y=153 width=38 height=1 count=0x0000
5.046 000:>:0235: Event EnterNotify(7) detail=Ancestor(0x00) mode=Ungrab(0x02) flags=same-screen time=0x05ee50bd root=0x0000026d event=0x00600003 child=None(0x00000000) root-x=702 root-y=319 event-x=128 event-y=102 state=Button1
5.046 000:>:0235: Event ButtonPress(4) button=left button(0x01) time=0x05ee50ba root=0x0000026d event=0x00600003 child=None(0x00000000) root-x=702 root-y=319 event-x=128 event-y=102 state=0 same-screen=true(0x01)

(Some of those expose events are presumably because of the various
requests and render requests it issued immediately after the LeaveNotify.)

In looking at this carefully, I did notice another anomaly in link.py's
behavior (which you may have also noticed). When I initially move the
mouse pointer over the actual link, it turns from a plain pointer into
a hand-pointer, presumably to signal that this is a clickable link, and
the program also pops up a tooltip for the link destination. When I
click on the link and nothing happens, this immediately changes back to
the regular pointer; in fact, this change happens on the button press
(which I can see if I click down and hold). This doesn't happen with
working clicks, where a button-press leaves the cursor unchanged.

I wonder if GTK is (mis-)processing the LeaveNotify here as 'the mouse
pointer is leaving the link', instead of 'mouse has been grabbed from me'.

- cks

Dominik Vogt

2017-03-01 20:38:27 UTC