https://bugs.winehq.org/show_bug.cgi?id=38201
Bug ID: 38201 Summary: Newly displayed dialogs have inactive-looking decorations although are actually active Product: Wine Version: 1.7.38 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: b7.10110111@gmail.com Distribution: ---
Created attachment 50980 --> https://bugs.winehq.org/attachment.cgi?id=50980 Screenshot of Windows (left) and Wine (right) MessageBox
If I uncheck "Allow the window manager to decorate the windows" in Graphics tab of winecfg, or just set wine to show all its windows in a virtual desktop or launch the apps like `wine explorer /desktop=a,1152x864 appname.exe`, their windows often look as inactive (gray title bar) while they are actually active. This is visible in particular in winecfg dialog, Mono/Gecko downloaders dialogs on wine prefix update, as well as with a simple program like this:
#include <windows.h> int main() { MessageBox(0,"Hello","Message",MB_OK); }
I've tested the code above in Wine and Windows XP, and in Windows it has correct active title (blue-lightBlue gradient), while in wine it has inactive title (gray-lightGray gradient).
If I make any other window active, then switch back to this one, it'll then show the correct title colors.
The attachment compares Windows' MessageBox with that of Wine, both untouched at the moment of screenshooting.
https://bugs.winehq.org/show_bug.cgi?id=38201
--- Comment #1 from Ruslan Kabatsayev b7.10110111@gmail.com --- Created attachment 50982 --> https://bugs.winehq.org/attachment.cgi?id=50982 Test with notepad-like window reproducing the problem
This is also visible in Wine's notepad. Because with normal windows even with children this doesn't immediately reproduce, I've studied what leads to this in notepad, and the trigger appears to be the call to SetFocus() before ShowWindow().
I attach a test program where you can see that commenting out the SetFocus() call or moving it below ShowWindow() will hide the bug, while running the program as is will reproduce the bug.
I've also checked this in Windows, and there no such behavior is present: newly-created toplevel window is always active at start.
https://bugs.winehq.org/show_bug.cgi?id=38201
Ruslan Kabatsayev b7.10110111@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #50982|0 |1 is obsolete| |
--- Comment #2 from Ruslan Kabatsayev b7.10110111@gmail.com --- Created attachment 50991 --> https://bugs.winehq.org/attachment.cgi?id=50991 Updated test case with more debug messages
It appears that in Windows SetFocus called on a not yet showed window makes its root ancestor the foreground window. On windows, its output is [1], with the following relevant pieces:
Window created; hwnd=0x000500d6, hEdit=0x00090132 ... msg=0x00000086,wP=0x00000001,lP=0x00000000 (WM_NCACTIVATE) ... Focus set Foreground window now: 0x000500d6
On wine, however, its output is [2], with the relevant pieces different:
Window created; hwnd=0x00010046, hEdit=0x0001004c ... msg=0x00000086,wP=0x00000000,lP=0x00000000 (WM_NCACTIVATE) ... Focus set Foreground window now: 0x00010020
I.e. there's a discrepancy between behavior of Wine's implementation of SetFocus() and Windows' one.
[1]: http://pastebin.com/eesSALFj [2]: http://pastebin.com/beKk60jN
https://bugs.winehq.org/show_bug.cgi?id=38201
--- Comment #3 from Ruslan Kabatsayev b7.10110111@gmail.com --- Created attachment 50992 --> https://bugs.winehq.org/attachment.cgi?id=50992 Attempt to fix
This patch makes the results more consistent with Windows, although I'm not quite sure whether it'll break anything.
https://bugs.winehq.org/show_bug.cgi?id=38201
Ruslan Kabatsayev b7.10110111@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #50992|0 |1 is obsolete| |
--- Comment #4 from Ruslan Kabatsayev b7.10110111@gmail.com --- Created attachment 50999 --> https://bugs.winehq.org/attachment.cgi?id=50999 Patch which seems to fix the issue, not breaking win.c test
Here's a better potential fix. This time it doesn't increase number of failures in win.c test.
https://bugs.winehq.org/show_bug.cgi?id=38201
--- Comment #5 from Ruslan Kabatsayev b7.10110111@gmail.com --- Actually this patch does not always work as Windows works, so it's bad. Something trickier is happening here.
https://bugs.winehq.org/show_bug.cgi?id=38201
--- Comment #6 from Ruslan Kabatsayev b7.10110111@gmail.com --- In any case, it seems that when a window gets real keyboard focus, i.e. when keyboard events will go into this window, it is not always represented as a foreground window in wine server.
The above doesn't even take into account that sometimes the window should become the foreground window even when it's invisible, as discussed in comment 2.
https://bugs.winehq.org/show_bug.cgi?id=38201
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch