[Bug 34315] New: HWND_NOTOPMOST makes window disappear behind other windows
http://bugs.winehq.org/show_bug.cgi?id=34315 Bug #: 34315 Summary: HWND_NOTOPMOST makes window disappear behind other windows Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: lopeonline(a)gmail.com Classification: Unclassified Created attachment 45681 --> http://bugs.winehq.org/attachment.cgi?id=45681 VB6 Test case (source code) AND exe Many of my utilities run minimized and are supposed to popup when they are ready for interaction. To make them popup I use this code: Me.WindowState = 0 BringWindowOnTop Me.Hwnd FlashWindow Me.Hwnd, True Me.Caption = "Popped up" Public Sub BringWindowOnTop(Hwnd As Long) SetWindowPos Hwnd, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE Or SWP_NOSIZE SetWindowPos Hwnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE Or SWP_NOSIZE SetWindowPos Hwnd, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOMOVE Or SWP_NOSIZE End Sub The above code works on XP and W7. On Wine as soon as I call HWND_NOTOPMOST the window falls behind other windows, unless I give the window focus before that happens. (that is not part of the submitted test case) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #1 from Bruno Jesus <00cpxxx(a)gmail.com> 2013-08-21 10:33:09 CDT --- What wine version? I can reproduce the issue in wine 1.6. As a workaround why not simply use HWND_TOP and remove the others? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #2 from Lope <lopeonline(a)gmail.com> 2013-08-21 10:42:32 CDT --- Hi Bruno, I have submitted this bug report and test program to help improve wine. ---------------------------- Regarding workarounds Your suggested workaround does not work. HWND_TOP by itself doesn't bring the window ontop of others so it stays behind whatever is on the screen. I have implemented a workaround that uses wine detection. I exclude the call to NOTOPMOST and then call NOTOPMOST once the user has clicked a button in my program. It ugly, but it works. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #3 from Lope <lopeonline(a)gmail.com> 2013-08-21 10:44:04 CDT --- I forgot to mention, I'm using Wine Version 1.6 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Version|unspecified |1.6 Ever Confirmed|0 |1 --- Comment #4 from Bruno Jesus <00cpxxx(a)gmail.com> 2013-08-21 12:00:05 CDT --- (In reply to comment #2)
Your suggested workaround does not work. HWND_TOP by itself doesn't bring the window ontop of others so it stays behind whatever is on the screen.
I don't know why it does not work for you, it did work for me in xfce. Certainly it will not get on top of other TOPMOST windows but it should go on top of standard windows at least. Anyway this is a really a bug. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #5 from Lope <lopeonline(a)gmail.com> 2013-08-21 12:22:54 CDT --- Hi Bruno When you do your test using HWND_TOP (only) make sure you set an appropriate delay such as 5000ms and as soon as you click the button, focus another window in its place. On windows XP you will find with HWND_TOP the window will remain behind other windows. I'm using Mate 1.6 desktop environment. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx(a)gmail.com --- Comment #6 from Bruno Jesus <00cpxxx(a)gmail.com> 2013-08-21 12:27:45 CDT --- You're completely right, on XP using TOP only will not put the window on top. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #7 from Lope <lopeonline(a)gmail.com> 2013-08-21 12:32:07 CDT --- A HWND_TOP window can only be on top of other HWND_TOP windows IF it's in focus. Simply setting HWND_TOP on a window actually does nothing besides clearing HWND_BOTTOM. You need TOPMOST to make it the most top window, because all windows are HWND_TOP. The value of HWND_TOP is 0. Its probably default when you create a window with pure API. To be really explicit: The wine bug is simply setting HWND_NOTOPMOST makes the HWND_TOP window fall behind another HWND_TOP window that is in focus. I expect this is a logic difference with how windows are positioned on Windows vs Linux. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #8 from Lope <lopeonline(a)gmail.com> 2013-08-21 12:38:11 CDT --- This is my understanding of the different behaviors in Win/Linux (which may be completely wrong) In windows any HWND_TOP window has an equal opportunity to be on top of another HWND_TOP window. It will be brought ontop of other windows by an event such as: * Focusing the window * Making the window TOPMOST temporarily and then returning it to NOTOPMOST. Wine/Linux seems to re-organize window Z-Order when setting NOTOPMOST which is wrong. NOTOPMOST is not supposed to trigger any Z-Order change. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 Ken Thomases <ken(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ken(a)codeweavers.com --- Comment #9 from Ken Thomases <ken(a)codeweavers.com> 2013-08-21 12:52:34 CDT --- (In reply to comment #8)
In windows any HWND_TOP window has an equal opportunity to be on top of another HWND_TOP window.
To be clear, there's no such thing as "an HWND_TOP window". HWND_TOP is not a property of a window. There are topmost windows (those with WS_EX_TOPMOST) and non-topmost windows.
Wine/Linux seems to re-organize window Z-Order when setting NOTOPMOST which is wrong. NOTOPMOST is not supposed to trigger any Z-Order change.
Well, surely changing a window from topmost to non-topmost should move that window behind any other topmost windows. But, presumably, the z-order change should be minimal, which would leave the formerly-topmost window in front of any other non-topmost window. If it wasn't already topmost, then it probably shouldn't change z-order. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #10 from Lope <lopeonline(a)gmail.com> 2013-08-21 13:18:57 CDT --- (In reply to comment #9)
To be clear, there's no such thing as "an HWND_TOP window". HWND_TOP is not a property of a window. There are topmost windows (those with WS_EX_TOPMOST) and non-topmost windows.
Yes I did explain that HWND_TOP is nothing special and did suggest that it is a attribute. However HWND_TOP=0 is listed in the WinAPI viewer 2004. (In reply to comment #9)
Wine/Linux seems to re-organize window Z-Order when setting NOTOPMOST which is wrong. NOTOPMOST is not supposed to trigger any Z-Order change.
Well, surely changing a window from topmost to non-topmost should move that window behind any other topmost windows. But, presumably, the z-order change should be minimal, which would leave the formerly-topmost window in front of any other non-topmost window. If it wasn't already topmost, then it probably shouldn't change z-order.
Yes I agree with your more accurate assessment. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #11 from Lope <lopeonline(a)gmail.com> 2013-08-21 13:20:38 CDT --- I meant to say "default attribute". -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #12 from Vincent Povirk <madewokherd(a)gmail.com> 2013-08-21 13:36:46 CDT --- Wine does very little z-order manipulation and instead relies on hints to the window manager. Trying to enforce the exact z-order semantics of Windows hasn't worked well with window managers, which also expect to control the z-order. The exception to this is that we raise a window when it becomes the topmost Wine window: http://source.winehq.org/source/dlls/winex11.drv/window.c#L1225 So it's not clear to me why HWND_NOTOPMOST would move your window behind anything, unless you're triggering a window manager behavior. Some window managers have protections against programs that spontaneously raise or steal focus. Does the same thing happen in a virtual desktop? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #13 from Lope <lopeonline(a)gmail.com> 2013-08-21 13:45:01 CDT --- (In reply to comment #12)
Does the same thing happen in a virtual desktop?
Hi Vincent, I don't understand your question. It happens on Mate 1.6. Thanks -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #14 from Lope <lopeonline(a)gmail.com> 2013-08-21 13:50:15 CDT --- I did a test where I set HWND_NOTOPMOST after an additional delay. As soon as HWND_NOTOPMOST is set, the window falls behind the window that is focused, so it does not seem to be conceptually related to the WM preventing it from stealing focus as it is already TOPMOST. Its just that NOTOPMOST triggers a re-ordering, that should not happen. In Windows its possible to have program F infront of program B while program B has focus and keystrokes go to program B. Is that possible in Linux? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #15 from Ken Thomases <ken(a)codeweavers.com> 2013-08-21 13:50:48 CDT --- (In reply to comment #12)
Wine does very little z-order manipulation and instead relies on hints to the window manager. Trying to enforce the exact z-order semantics of Windows hasn't worked well with window managers, which also expect to control the z-order.
The exception to this is that we raise a window when it becomes the topmost Wine window: http://source.winehq.org/source/dlls/winex11.drv/window.c#L1225
The above is specific to the X11 driver, not Wine generally. (Yes, this case is on Linux and so would be using the X11 driver.) Also, just to be clear, your use of "topmost" is not the Win32 notion of "topmost". You just mean frontmost.
So it's not clear to me why HWND_NOTOPMOST would move your window behind anything, unless you're triggering a window manager behavior. Some window managers have protections against programs that spontaneously raise or steal focus.
I was wondering the same thing. I wonder if Wine re-asserts focus and the window manager raises the focused window. The original report says the problem doesn't happen if the window is focused before those SetWindowPos() calls.
Does the same thing happen in a virtual desktop?
Good question/suggestion. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 --- Comment #16 from Bruno Jesus <00cpxxx(a)gmail.com> 2013-08-21 14:00:44 CDT --- On the virtual desktop the window comes to front but without focus. If only HWND_TOP is sent it will get in front and with focus. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
https://bugs.winehq.org/show_bug.cgi?id=34315 winetest(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de, | |winetest(a)luukku.com --- Comment #17 from winetest(a)luukku.com --- With wine 2.0rc4 the application vanishes after clicking the button, with wine-staging 2.0rc4 the gui comes back after clicking. I think this is dupe and recent change in wine-staging fixed this. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34315 KRosUser <kyle.kcsoftwares@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle.kcsoftwares@gmail.com --- Comment #18 from KRosUser <kyle.kcsoftwares@gmail.com> --- Wine 11.3 : Pressing the button makes the application vanish and come back as expected FIXED, to be CLOSED -- 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.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla