[Bug 40828] Switching resolution in desktop mode makes task bar redraw on top of full screen game

wine-bugs at winehq.org wine-bugs at winehq.org
Sun Jan 6 00:13:06 CST 2019


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

--- Comment #21 from Olivier F. R. Dierick <o.dierick at piezo-forte.be> ---
I found those observations by chromium developers:

--- quote ---
(...) In XP and Vista, the taskbar has a user-configurable "Keep taskbar on top
of other windows" option. When this is disabled, the taskbar is not a topmost
window (...)
When a fullscreen window exists (whether topmost or not), the Win OS will
manipulate the taskbar's topmost property and z-order as necessary when
switching between windows.
--- quote ---
https://bugs.chromium.org/p/chromium/issues/detail?id=320107

(In reply to Zebediah Figura from comment #20)
> Created attachment 63197 [details]
> adjusted version of Olivier's patch
> 
> When an application makes itself fullscreen, does that involve anything more
> than just setting its window to the size of the whole screen? Does it make
> the window topmost as well? Is there some other magic involved?

The conditions for fullscreen are:
- Same size as the desktop.
- No caption or border window styles.
The taskbar somehow checks those conditions on the active window and removes
itself when they are met.

Topmost status of the fullscreen window is left to the app developer and
doesn't matter for the taskbar.
For example, you may have a non-topmost fullscreen window that makes the
taskbar disappear, and topmost non-fullscreen windows that appear above the
fullscreen window.

> IIRC, a normal window always goes behind the taskbar on Windows, and a
> topmost window always goes over it. That's certainly consistent with the
> taskbar being topmost itself (and, I guess, unfocusable?)

It depends on the Windows version, but from the quote above I gather that the
taskbar is topmost until it detects a fullscreen window and it removes itself.
Note that the z order is undefined when there is more than one topmost window.

I don't know if the taskbar should be drawn under or over the other topmost
windows. I guess that for security reasons we may enforce that the taskbar is
on top of everything when there is no fullscreen window ?

> Why is do_show_systray() called in show_icon()? The conditions under which
> the taskbar is shown are, I suppose, not immediately clear.

The taskbar is designed to auto-hide when the last icon is removed from the
systray and auto-show when the first icon is added. In the current state, if
the taskbar is hidden and an app adds an icon while there is a fullscreen
window, the taskbar will appear over the fullscreen window. It should be
disabled when a fullscreen window is detected.

> I think the approach of using SWP_NOZORDER makes sense in principle; when
> the display changes we need to resize the taskbar, but we don't want to
> reorder it. However, unless I'm mistaken SWP_NOZORDER implies that the
> ordering parameter to SetWindowPos() is ignored entirely, so I'd do
> something like the attached instead. Does this make more sense?

SWP_NOZORDER tells the function to ignore the HwndInsertAfter parameter, but it
sure looks better and more consistent to not set HWND_TOPMOST either.

Mmm. Setting WS_EX_TOPMOST on tray creation will require that the tray detects
when a fullscreen window is active and removes itself, just like Hamish
Claxton's patch does.
- If the fullscreen window is topmost, the taskbar must be removed to avoid
undefined behaviour.
- If the fullscreen window is not topmost, the taskbar must be remove to avoid
being drawn over the non-topmost fullscreen window.

I guess we need to mix both approach. So I suggest that Hamish Claxton merge
your adjusted version of my patch with his own.

-- 
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.



More information about the wine-bugs mailing list