http://bugs.winehq.org/show_bug.cgi?id=60266 Bug ID: 60266 Summary: Window above a full-screen window is drawn behind it Product: Wine Version: 11.14 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs@list.winehq.org Reporter: realmaitreal@deadmail.lat Target Milestone: --- Created attachment 81984 --> http://bugs.winehq.org/attachment.cgi?id=81984 Minimal Win32 reproducer (C source, ~130 lines, no dependencies) Overview A window which the application places above a full-screen window in the Win32 z-order is drawn behind it and is invisible, when the application owns its windows from a common owner window, as Delphi applications do. winemac.drv elevates a full-screen window to NSStatusWindowLevel+1 while the application is active. Reordering or attaching an owned window goes through -[NSWindow addChildWindow:ordered:], which resets window levels. The owner window is not itself full-screen, so it stays at NSNormalWindowLevel, and the attach drops the affected windows to that level. Because the window level dominates the window server ordering, those windows are then ordered behind the full-screen window and are never promoted again by -adjustWindowLevels:, which decides which windows are "in front" from that same ordering. That -addChildWindow: resets a window level is not documented by Apple. Electron saves and restores the parent window's level around the call for this reason: https://github.com/electron/electron/pull/38460 Measured here with CGWindowListCopyWindowInfo(): attaching a newly created dialog also dropped an existing sibling window from level 27 to level 0. Steps to Reproduce Build and run the attached reproducer (about 130 lines, plain Win32): i686-w64-mingw32-gcc -O1 -o repro.exe repro.c -lgdi32 -luser32 -mconsole wine repro.exe It creates four windows, mirroring a Delphi application's arrangement: 1) APP - a 1x1 owner window, created first so it stays at the back and is never elevated (Delphi's hidden TApplication window) 2) MAIN - a full-screen window, owned by APP 3) START - an ordinary window, owned by APP 4) SPLASH - the window which must stay visible, owned by APP Click the WHITE window (SPLASH) so the application becomes active without raising the black full-screen window in the z-order. The program then swaps START and SPLASH in the z-order once per second with SetWindowPos(hwnd, HWND_TOP, ...) and prints the resulting Win32 z-order. Actual Results The white window is invisible while the application is active, although the program reports it as the top of the Win32 z-order: win32: SPLASH > START > MAIN > APP CGWindowListCopyWindowInfo() reports MAIN at window level 26 (NSStatusWindowLevel+1) and SPLASH, START and APP at level 0. All four are on the same Space and all are ordered in; the white window is simply drawn underneath. It reappears as soon as the application is deactivated, and is visible in Mission Control, which ignores window levels. Reproduced on 20 of 20 samples. Expected Results The white window should be drawn over the full-screen one. Windows has no notion of a full-screen window in the z-order. Per "Window Features": "The system maintains the z-order in a single list. It adds windows to the z-order based on whether they are topmost windows, top-level windows, or child windows." "A child window is grouped with its parent in z-order." Position in the z-order is therefore determined by window type, not by a window's size, so a window which happens to cover the screen has no special standing. SetWindowPos() with HWND_TOP "Places the window at the top of the Z order", and after that call the window must not remain obscured. https://learn.microsoft.com/en-us/windows/win32/winmsg/window-features https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwi... Build Date & Hardware wine-11.14, macOS 26.6.2 (Darwin 25.6.0), Apple Silicon running the x86_64 build. -addChildWineWindow:, -setChildWineWindows: and -adjustWindowLevels: are byte-identical in 11.16 and in current master, so those are affected too. Additional Information Found with OMSI 2 (Steam appid 252530): the loading form is invisible for the whole of a map load, leaving a black screen, and the "really quit?" dialog is invisible as well. Both reappear if the application is deactivated and reactivated. The application must be active for the bug to appear, because the elevation only applies while it is. The similar reports Bugzilla suggests (13515, 22944, 31370, 35384, 56021, 58537, 59334) are all on Linux; none is against winemac.drv. -- 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.