On Sat Sep 28 20:47:21 2024 +0000, Paul Gofman wrote:
How do we end up in the case where new_thread is 0 exactly? Is this
because of a `SetForegroundWindow( 0 )` call or `SetActiveWindow( 0 )`? No, we end up 0 new thread id with SetForegroundWindow() regardless of the argument. See win32u/input.c:set_foreground_window(). set_active_window() is always called twice, once for the thread / windows loosing foreground and once for the new thread / windows gaining foreground. On line 2129 set_active_window() is explicitly called with NULL hwnd (which warrants 0 new_thread_id). On line 2126 (a different thread configuration case) WM_WINE_SETACTIVEWINDOW is called with NULL hwnd (wparam), that will result in set_active_window() with NULL thread called by WM_WINE_SETACTIVEWINDOW handler (through NtUserSetActiveWindow). This logic so far looks all correct WRT proper WM_ACTIVATEPP delivery logic (when it is delivered and when not; the threads which do that). The issue I am concerning is only lparam (thread id) for WM_ACTIVATEPP in the first set_active_window call (for the thread / windows which are loosing foreground). Passing the new_thread_id as lparam looks plainly wrong to me, it is probably guaranteed to be 0 for the loosing focus thread (and for the cases when it maybe won't, like SetActiveWindow, WM_ACTIVATEPP won't be sent at all because SetActiveWindow only works withing the same thread windows while WM_ACTIVATEPP is only sent when the active thread changes).
Maybe I could use that TID from server only when hwnd for set_active_window() is NULL, to leave the logic intact when set_active_window() is used SetFocus or SetActiveWindow.