bug#6372: 24.0.50; C-mouse-1 activates region

[Drew Adams]

ping.

> From: Eli Zaretskii Sent: Saturday, July 21, 2012 4:42 AM
> I'm sorry, but it will take someone who knows more than I do about
> MS-Windows messages and their processing to fix this one.  I describe
> my findings below in the hope that someone will pick up where I left
> off.
> 
> We track mouse events during pop-up menu by sending the
> WM_EMACS_TRACKPOPUPMENU message to the Emacs message pump.  This
> message is handled by w32_wnd_proc around line 3770 of w32fns.c.
> There, we call TrackPopupMenu, a Windows API that displays the menu
> and returns the user selection of menu items.  After TrackPopupMenu
> returns, we remove any mouse events still in the message queue, by
> calling PeekMessage with appropriate arguments, and return the user
> selection to our caller, which is w32_menu_show.  The user selection
> returned is zero when the user closes the menu without selecting any
> item, by clicking outside the menu.  w32_menu_show then removes any
> mouse events in the Emacs event queue by calling discard_mouse_events.
> 
> What happens in this case, and is the reason for the bug, is that
> somehow the mouse click event that pops down the menu is not delivered
> to Emacs until _after_ w32_menu_show returns.  That click is not
> removed by PeekMessage mentioned above, and is not discarded by
> discard_mouse_events.  It is read by w32_wnd_proc only after all of
> the above processing is complete, and any memory of the menu that was
> popped down is gone.  So Emacs processes that mouse click as a normal
> event, oblivious to the fact that it actually happened as part of the
> menu.
> 
> What I don't understand here is why that mouse click is not delivered
> when we call PeekMessage, so that it could be discarded.  It's as if
> Windows withholds that message from being put into the Emacs message
> queue.  Why is that, and what can we do to be able to peek at that
> click message as part of menu processing and discard it, is beyond me.