Hello, This was reported by a Debian user. Please retain the CC to 849354-forwar...@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
