[Bug 38201] New: Newly displayed dialogs have inactive-looking decorations although are actually active

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(a)winehq.org
          Reporter: b7.10110111(a)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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 38201] Newly displayed dialogs have inactive-looking decorations although are actually active

https://bugs.winehq.org/show_bug.cgi?id=38201

--- Comment #1 from Ruslan Kabatsayev <b7.10110111(a)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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 38201] Newly displayed dialogs have inactive-looking decorations although are actually active

https://bugs.winehq.org/show_bug.cgi?id=38201

Ruslan Kabatsayev <b7.10110111(a)gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #50982|0                           |1
        is obsolete|                            |

--- Comment #2 from Ruslan Kabatsayev <b7.10110111(a)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

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 38201] Newly displayed dialogs have inactive-looking decorations although are actually active

https://bugs.winehq.org/show_bug.cgi?id=38201

--- Comment #3 from Ruslan Kabatsayev <b7.10110111(a)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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 38201] Newly displayed dialogs have inactive-looking decorations although are actually active

https://bugs.winehq.org/show_bug.cgi?id=38201

Ruslan Kabatsayev <b7.10110111(a)gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #50992|0                           |1
        is obsolete|                            |

--- Comment #4 from Ruslan Kabatsayev <b7.10110111(a)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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 38201] Newly displayed dialogs have inactive-looking decorations although are actually active

https://bugs.winehq.org/show_bug.cgi?id=38201

--- Comment #5 from Ruslan Kabatsayev <b7.10110111(a)gmail.com> ---
Actually this patch does not always work as Windows works, so it's bad.
Something trickier is happening here.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 38201] Newly displayed dialogs have inactive-looking decorations although are actually active

https://bugs.winehq.org/show_bug.cgi?id=38201

--- Comment #6 from Ruslan Kabatsayev <b7.10110111(a)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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 38201] Newly displayed dialogs have inactive-looking decorations although are actually active

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=38201

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.