Since I've upgraded fvwm from 1:2.6.5.ds-4.1 to 1:2.6.7-2 (last night),
I have the following problems. I have the following in my config:

Mouse 1         A       SCM     Raise

1. If the window is not yet on top, then it is not always raised.
Well, I'm not sure. It could be problem 2. See below.

2. If the window is already on top, then this sometimes freezes the
desktop: I can't do anything until I do another click.

I'd say that problem 1 occurs at around 1 over 10. AFAIK, it had never
occurred before the upgrade.

Problem 2 can occur at around 1 over 10, but sometimes it occurs
several times in a row. I don't know whether it is new, since I had
probably never done tests before. FYI, I've noticed it when I was
trying to find the cause of problem 1: I tried with xev to see if
the clicks were always reported[*], where the xev window is usually
on top.

[*] The result is that they seem to be.

Now, back to problem 1, I think that what I always did is to try
again, so that the window is raised. But with more tests, it actually
seems to be problem 2, i.e. the desktop is frozen, and the window is
not raised *as a consequence*! If I click anywhere (without SCM held),
then the window is raised, which would confirm that this is problem 2.

Note: I have not changed my FVWM config except the replacement of
FvwmWinList by FvwmIconMan (since FvwmWinList is no longer available
in FVWM 2.6.7).

and the problem is reproducible with just this line in the config file.

I've downgraded to 2.6.5, and I could reproduce the problems, which
are the same IMHO.

When I SCM-click over a window that is not yet on top and the problem
occurs, I can:
  1. Click anywhere, and the window is raised. Back to normal.
  2. Hit [Return], and the window is raised. Back to normal.
  3. Hit [Escape], and the window is not raised. Back to normal.
  4. The arrow keys move the mouse pointer; with the Shift key, faster.
     Ditto with b, f, h, j, k, l, n, p.

Most keys do not have any effect. So, this seems to be a FVWM feature
(SCM-click over the root window is similar, and this is normal in this
case), but this feature is triggered when it should *not* be.

Thank you for your bug report.

It seems to me the issue is with the context A (anywhere) in your binding.
When you run the Raise function. Since this can be done Anywhere, the
context of which window to Raise may not be correctly set.

I don't know the details completely, but my understanding is if the
context is not
set to a window, Raise will want you to pick the window to raise, so
it will pause
fvwm and let you click on the window you want to raise.

It may also be the context is set to a different window than you
expect. This could also explain the inconsistency of being able to
reproduce it, since most times when you use the binding the context is
as you expect it to be and the correct window is raised, but sometimes
it is not, in which case you either have fvwm pause for you to pick
the window to raise or it preforms the action on a different window.

Two solutions would be to narrow the context to say the window and its
decorations, FSTW, or wrap the Raise command into a function on use a
conditional (such as ThisWindow or Current) to force the context. More
on the context for functions can be found here:

http://fvwmforums.org/wiki/Config/FunctionContext/

jaimos

But this is not what I observe. Well, if I click over the root window,
I get this behavior as expected, and this is fine. Note that concerning
the problem I've reported, I always clicked inside the window to be
raised. Note also that if:
  * I SCM-click inside Window A,
  * the problem occurs,
  * I click inside Window B,
then it is Window A that is raised, not Window B. This means that FVWM
knew really which window had to be raised.

Note also that when FVWM wants me to pick the window to raise (e.g.
after a SCM-click over the root window), the mouse pointer changes
to a cross. But when the problem occurs, the mouse pointer remains
the same as usual and still changes depending on the context as
usual.

I don't understand what you mean.

I suppose that the context is correct since FVWM raises the correct
window after a click anywhere (see above). To be sure, I wanted to
test with:

AddToFunc RaiseDbg
+ I Echo $[w.name]
+ I Raise

Mouse 1		A	SCM	RaiseDbg

but I can't reproduce the problem with this!

Actually, I've now found that what matters was not the upgrade,
but the fact that I had been using this config (a bit recent)
only with a real mouse, and the problems started to appear only
when I used the touchpad of my laptop.

After doing more tests with xev, I've noticed that the time delta
between the ButtonPress event and the ButtonRelease event was in
general much lower with the touchpad: about 120 units with the
mouse button, but sometimes less than 10 units with the button
of the touchpad.

Then I tried to reproduce the problem with the touchpad but letting
the touchpad button pressed a bit longer, and I couldn't.

So, it seems to be a timing issue in Fvwm. Perhaps it "forgets" the
ButtonRelease event, since the behavior when the bug occurs is similar
to what happens when I SCM-press the button but don't release it.

In reviewing this I have a theory, the time is so low there is a race condition.
Fvwm gets and maybe ignores the release event before fvwm fully processes
the push event. Then fvwm gets stuck waiting for a release event, which
happens the next time you clicked the mouse button.

When using the function wrapper, this wouldn't happen because the function
wrapper due to holds, double clicks, etc, would not necessarily we waiting
for a release event like the mouse binding might be.

Wonder how common it is for the times between clicks and releases to be
that low, or if this bug is more an artifact of that hardware or
touchpad drivers.

jaimos

Hello,

This was reported by a Debian user. Please retain the CC to
849354-forwarded@bugs.debian.org in your response, so that
the Debian BTS has a record.

The full bug report can be found at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849354

In summary I think the bug that the user experiences is due to the
time between a ButtonPress and ButtonRelease event being to quick. The
user has a binding that looks like this:

Mouse 1         A       SCM     Raise

Sometimes when clicking on a window to raise it, fvwm will not
register the click fully and then be put into a wait state until the
mouse is clicked a second time, at which time the window is raised.
After some investigation the user discovered that it only happened
with their touchpad and further by looking at xev, only happened when
the time difference between the Press and Release events were less
than 10 units by xev (about 10+ times faster than the times registered
with a normal mouse button). Additionally the user discovered if they
wrapped the Raise call into a function or just held down the button a
little bit longer, the bug did not happen.

My theory is the time is so low there is a race condition. Fvwm gets
and maybe ignores the release event before fvwm fully processes the
press event. Then fvwm gets stuck waiting for a release event, which
happens the next time the mouse is clicked.

When using the function wrapper, this wouldn't happen because the function
wrapper might not necessarily we waiting for a release event like the
mouse binding might be.

So could there be some issue that causes fvwm to pause with such a
binding, as the push would put fvwm in a state that forces it to wait
for the release event to register the click as happening to trigger
the binding, and could a fix be have some timeout while fvwm is
waiting for the release button in this case?

In addition if I make such a binding and then click and hold my mouse
button, fvwm is put into a wait state and won't function until I
release my mouse button, so this seems to help support my theory that
the pause is due to fvwm waiting for the release event. So last
question, could a timeout be useful here to ensure fvwm won't pause
too long waiting for a release event, or is there some reason fvwm
needs to wait for the release event and this is just an issue with the
touchpard hardware sending to quick of press/release events?

Thanks for your time,

jaimos

Hi,

I'm afraid, despite all the suggestions mentioned, that I can't reproduce
this problem.

Can you pleae ensure you're able to reproduce this problem with fvwm2 built
from master, and if necessary, supply the minimal fvwm2rc file which shows
this problem?

One thing to bear in mind, when functions are involved, they'll grab the
XServer.  I'm wondering if you're noticing this on a laptop specifically
because of the ms timeouts on what FVWM considers a single click and a
doubleclick?

Kindly,
Thomas

I am not able to reproduce the bug, but I can reproduce what I think
the behavior is. Consider the following keybinding

Mouse 1 A SCM Raise

Then use the binding to raise a window. If you hold down the mouse
button, the Raise doesn't happen until after the release. While the
mouse button is held down fvwm seems to be in a semi frozen state, as
if it is waiting for the release event. While holding down the button
(hold it for a couple of minutes), nothing in fvwm is updated, focus
is not changed as I move the mouse around with SloppyFocus, other key
bindings do not work, FvwmButtons ActiveColorsets do not change when
hovered above them, and so on. But as soon as the release happens
things go back to normal.

Due to the info from the original reporter about timing between the
press and release events, it appears that if the release event happens
so quickly after the press event, that by the time fvwm starts to wait
for a release event, the event has already happened. And it isn't
until another click (which causes a release event) that fvwm then
raises the window and continues on.

Anyways, I think the cause of this bug is bad hardware, since it seems
only this one laptop touchpad seems to produce press/release events so
quickly to get fvwm stuck in such a state.

jaimos

IIRC, I couldn't reproduce the issue after the 2016-12/2017-01 period.
Note that at home, I was using a real mouse, but each time I wasn't
at home (which occurred several times per year), I was using the
touchpad. I've used this laptop until 2023. And I still have and use
the "Mouse 1 A SCM Raise" config (now with different hardware).

It might also have been due to a kernel / systemd / X11 related issue.