Improper message recursion revealed by recent desktop window changes

[Troy Rollo]

The recent changes to the desktop have revealed a problem with recursive 
processing of X messages. The problem started to manifest with commit 
1a4f6e579b6aab685fae2e649fd5accee7ec0b4f (7th March). A symptom is a stack 
that looks like this:

	<application Window procedure>
	WINPROC_wrapper
	  ...
	CallWindowProcW
	 ...
	SendMessageW
	X11DRV_SetWindowPos
	SetWindowPos
	X11DRV_ConfigureNotify
	process_events
	X11DRV_MsgWaitForMultipleObjectsEx
	wait_message_reply
	send_inter_thread_message
	SendMessageTimeoutW
	SendMessageW
	send_parent_notify
	DestroyWindow

In other words, a destroy notification is being sent to the parent window with 
SendMessageW, and before that message returns an unrelated X message is 
processed. Under Windows the equivalent could never happen - if a thread is 
in SendMessage(), the only messages that can be delivered to it are ones sent 
by SendMessage() from another thread.

The consequences of this can be unpleasant if the code that processes (in this 
case a window movement notification) the message interferes with state that 
is being dealt with in earlier stack frames.

wait_message_reply calls X11DRV_MsgWaitForMultipleObjectsEx with:

res = USER_Driver->pMsgWaitForMultipleObjectsEx( 1, &server_queue,
                                             INFINITE, QS_ALLINPUT, 0 );

The brute-force approach of changing this to the following makes the 
application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT 
and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to 
change I thought it best left to people with more familiarity with it.

-- 
Troy Rollo - wine at troy.rollo.name