Some window managers have trouble moving fullscreen windows to another monitor. For example, KWin
doesn't allow moving windows with _NET_WM_STATE_FULLSCREEN set. FVWM used by TestBots keeps
the size for fullscreen windows after they are moved to another monitor and when the window is also
fullscreen on the new monitor, which could be a bug in FVWM. But let's work around this in the tests
as well. The changed tests don't need created windows being fullscreen at the start.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54172
To ensure a seamless transition between value names, we try loading the
registry value from FontFamily first and FontPitchFamily second.
Any changes to the console font family are saved to the new value name.
SetWindowIcon can pass an icon as a parameter, but in that case
NtUserGetIconInfo is never called, so the icon info is never filled.
Fixes a regression introduced by 3eb944c0a7.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
There are cases in Windows10+ where the WM_PASTE message doesn't paste
the content of the clipboard.
This appeared in testing:
- almost always just after (for a couple of milliseconds) setting new
content into the clipboard and closing it.
- in some unrelated rare occasions (like once for 400 runs).
It looks like another (installed) process had opened the clipboard and
forbids the paste command.
As WM_PASTE doesn't return success/error status, workaround it by
wrapping the WM_PASTE command into a helper, and retry when the
clipboard's content hasn't been pasted.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53276
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53277
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
As the clipboard is a shared resource, we cannot expect that
no other app hasn't openeded it.
So wrap clipboard access with a retry feature in case of failure.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
There are cases in Windows10+ where the WM_PASTE message doesn't paste
the content of the clipboard.
This appeared in testing:
- almost always just after (for a couple of milliseconds) setting new
content into the clipboard and closing it.
- in some unrelated rare occasions (like once for 400 runs).
It looks like another (installed) process had opened the clipboard and
forbids the paste command.
As WM_PASTE doesn't return success/error status, workaround it by
wrapping the WM_PASTE command into a helper, and retry when the
clipboard's content hasn't been pasted.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53276
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
As the clipboard is a shared resource, we cannot expect that
no other app hasn't openeded it.
So wrap clipboard access with a retry feature in case of failure.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
The pSignatureSettings field was not unitilized so it got a random value from
the stack causing a later crash when it was dereferenced in Wintrust
(SoftPubloadSignature).
I was unable to write tests for this; it seems it doesn't consistently work on
Windows. However, Rayman 3 seems to rely on it; it maps the same buffer twice
immediately after creation, with DISCARD flags on both maps, and expects the
same address to be returned.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53752
The code originally intended to achieve this by simply waiting on flushing_cs,
and having the application thread hold flushing_cs while seeking. Unfortunately,
this can result in starvation of the application thread, since the streaming
thread always reacquires flushing_cs immediately after releasing it. Avoid this
by using a separate condition variable.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53403
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
The code previously relied on inherent atomicity of atomic types, but atomicity
doesn't imply the right memory ordering. Be explicit about the threading model
we want.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Starting with Win10, height of multiline edit controls no longer seems
to be hardwired to a multiple of the font height (when larger than
font height).
- Adapt the tests accordingly (detecting how to compute the expected
height of a control).
- Extend the ranges of the tested heights.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52152
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
