event: Handle MotionNotify before ButtonPress/Release (FS#1136)

The above-mentioned bug report says that a window cannot be moved via its
titlebar if you move the move quickly while clicking.

The reason for this was awesome's "event compression": We don't handle all
MotionNotify events, because they can come in big quantities. Instead, we only
want to handle the latest one and ignore all earlier ones (the mouse isn't in
that position anymore anyway).

The problem now appears if a MotionNotify is moved across a ButtonPress event
and the ButtonPress is what should cause the window to be moved. Awesome first
handles the ButtonPress event normally and starts grabbing mouse input. Then,
our event loop feeds us with an old MotionNotify event in which the button was
not pressed yet. The code for moving clients gets a motion event in which no
mouse button is pressed, concludes that the move is done and ungrabs the mouse
again, even though the button is still physically pressed.

Fix this by making sure that MotionNotify events are never moved across
ButtonPress or ButtonRelease events. We already did this for EnterNotify and
LeaveNotify events for similar reasons.

Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit is contained in:
Uli Schlachter 2013-10-06 10:34:37 +02:00
parent db167ebe80
commit efd243b6d7
1 changed files with 4 additions and 4 deletions

View File

@ -181,13 +181,13 @@ a_xcb_check(void)
else
{
uint8_t type = XCB_EVENT_RESPONSE_TYPE(event);
if((type == XCB_ENTER_NOTIFY || type == XCB_LEAVE_NOTIFY) && mouse)
if(mouse && (type == XCB_ENTER_NOTIFY || type == XCB_LEAVE_NOTIFY
|| type == XCB_BUTTON_PRESS || type == XCB_BUTTON_RELEASE))
{
/* Make sure enter/motion/leave events are handled in the
* correct order */
/* Make sure enter/motion/leave/press/release events are handled
* in the correct order */
event_handle(mouse);
p_delete(&mouse);
mouse = NULL;
}
event_handle(event);
p_delete(&event);