[PATCH 1/5] user32/tests: Add tests for GetWindowPlacement() and SetWindowPlacement().

[Gabriel Ivăncescu]

On 2/14/19 6:01 PM, Zebediah Figura wrote:
> On 2/14/19 4:25 AM, Gabriel Ivăncescu wrote:
>> On 2/14/19 6:17 AM, Zebediah Figura wrote:
>>> On 2/13/19 2:16 PM, Alexandre Julliard wrote:
>>>> Zebediah Figura <z.figura12 at gmail.com> writes:
>>>>
>>>>> On 2/10/19 1:39 PM, Marvin wrote:
>>>>>> Hi,
>>>>>>
>>>>>> While running your changed tests on Windows, I think I found new
>>>>>> failures.
>>>>>> Being a bot and all I'm not very good at pattern recognition, so I
>>>>>> might be
>>>>>> wrong, but could you please double-check?
>>>>>>
>>>>>> Full results can be found at:
>>>>>> https://testbot.winehq.org/JobDetails.pl?Key=47392
>>>>>>
>>>>>> Your paranoid android.
>>>>>>
>>>>>>
>>>>>> === wvistau64 (32 bit report) ===
>>>>>>
>>>>>> user32:
>>>>>> win.c:10796: Test failed: got minimized pos (0,713)
>>>>>> win.c:10808: Test failed: got minimized pos (0,713)
>>>>>> win.c:10820: Test failed: got minimized pos (0,713)
>>>>>> win.c:10833: Test failed: got minimized pos (0,713)
>>>>>> win.c:10846: Test failed: got minimized pos (0,713)
>>>>>> win.c:10859: Test failed: got minimized pos (0,713)
>>>>>> win.c:10872: Test failed: got minimized pos (0,713)
>>>>>> win.c:10906: Test failed: got minimized pos (100,100)
>>>>>> win.c:10928: Test failed: got minimized pos (100,100)
>>>>>>
>>>>>
>>>>> *snip*
>>>>>
>>>>> This fails because test_shell_window(), which is pretty pathological,
>>>>> kills explorer.exe, and that doesn't restart itself until the test
>>>>> program terminates. What can be done about this, if anything?
>>>>
>>>> The obvious fix is to run your test before the one that kills the shell
>>>> window. Though if the behavior depends on having a shell window, it may
>>>> be interesting to test both cases.
>>>>
>>>
>>> Thanks. I guess I wasn't sure if that was an acceptable solution.
>>>
>>> I guess the behaviour here makes sense—if there's no shell window, there
>>> won't be a taskbar, and so windows would have no way of being restored
>>> if they're minimized offscreen. But I'm also not sure it's something
>>> that there's any point replicating in Wine (either windows are offscreen
>>> anyway due to WM integration, or explorer.exe is necessary to run the
>>> virtual desktop), so I'll leave off testing this, unless you think it'd
>>> be better to do so.
>>>
>>>
>>
>> Hi Zeb,
>>
>> Just wondering, could this (missing) behavior have something to do with
>> https://bugs.winehq.org/show_bug.cgi?id=15346
>>
>>
> 
> It's not immediately evident to me why it would, I guess? Does the 
> program call SetShellWindow()?
> 
> 

It calls SetWindowPos when it's being moved, however, the problem is 
that somehow it ends up snapped to negative coordinate (e.g. -width of 
window) when moved to the edge (it "snaps" to the edge on either side).

X11 driver code then unmaps this window because it's "out of screen", so 
it disappears. My workaround patch in that bug report queries the X11 
server for the actual position because the WM will deny the negative 
placement, and it seems to work. However I'm not certain it's the proper 
solution because I think the negative placement shouldn't happen in the 
first place. No idea why it does.

But it probably has nothing to do with it as you said, I didn't look 
into it so I assumed it had something to do with WM integration, because 
you mentioned it. But nevermind, thanks for the answer. :-)