http://bugs.winehq.org/show_bug.cgi?id=15346
Summary: Winamp disappears when you move it's location Product: Wine Version: 1.1.5 Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: homerhomer@gmail.com
Created an attachment (id=16178) --> (http://bugs.winehq.org/attachment.cgi?id=16178) DwmSetWindowAttribute error
Sort of a silly bug, basically once winamp is up and running, if you click on the title bar and move it around winamp disappears. To make sure that the bug happens make sure to swirl it around a couple of times. ( A Swirly if you will )
Attached I also noticed this when running winamp manually at startup. This may be related. but then I move winamp and it disappears I don't get any more error messages. So I'm not sure. I appreciate the good work
Thank you
I'm running Ubuntu 8.04, Wine 1.1.5, AMD64
http://bugs.winehq.org/show_bug.cgi?id=15346
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
--- Comment #1 from Lei Zhang thestig@google.com 2008-09-27 16:22:06 --- Which version of Winamp?
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #2 from mike homerhomer@gmail.com 2008-09-27 21:20:26 --- The version 5.541
http://bugs.winehq.org/show_bug.cgi?id=15346
Arkadiusz Piekarz piekarzarkadiusz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |piekarzarkadiusz@gmail.com
--- Comment #3 from Arkadiusz Piekarz piekarzarkadiusz@gmail.com 2008-10-04 19:03:41 --- Winamp windows indeed disappear, but only if you try to move them outside of the desktop. Happens both in Metacity and Compiz. The system monitor shows that Winamp still works, but its windows can't be seen.
Winamp 5.541, Wine 1.1.5, Ubuntu 8.04, Ati Radeon x2300, 8.9 official drivers.
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #4 from Marc Menghin marc.menghin@gmail.com 2008-12-06 08:43:39 --- I can confirm this. The problem seems to me that while moving the windows very fast it gets wrong positions (or position changes). This leads to the result that the windows get places off screen. It did not happen so far on slow movement of the windows.
So windows are still there and work fine, they are just outside the screen.
How to reset the windows is explained here: http://forums.winamp.com/showthread.php?threadid=164598
http://bugs.winehq.org/show_bug.cgi?id=15346
Jaime Rave jaimerave@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jaimerave@gmail.com
--- Comment #5 from Jaime Rave jaimerave@gmail.com 2008-12-06 10:24:58 --- This also affect Winamp 2.95
http://bugs.winehq.org/show_bug.cgi?id=15346
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #6 from Lei Zhang thestig@google.com 2008-12-07 03:13:54 --- confirming then.
http://bugs.winehq.org/show_bug.cgi?id=15346
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |seppo.yli-olli@iki.fi
--- Comment #7 from Juan Lang juan_lang@yahoo.com 2008-12-11 21:21:57 --- *** Bug 16473 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #8 from Seppo Yli-Olli seppo.yli-olli@iki.fi 2008-12-12 05:11:25 --- I'd like to note that for me it's not just a swirly move that makes it disappear. It can be a slow one too but it has to happen near the workspace edge. The edge seems to suck Winamp straight out of the workspace making it invisible. Swirling fast in the middle of the screen seemed harmless to me if it stays clear of workspace edges. (So I don't think it's related to the fast moving at all, rather desktop environment workspace switching being attempted and being failed. Are Wine windows supposed to be capable of doing that?) It would also explain why they seem to be "outside the screen". Adjacent workspaces are technically outside the screen.
http://bugs.winehq.org/show_bug.cgi?id=15346
Daniel flamehawk96@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |flamehawk96@yahoo.com
--- Comment #9 from Daniel flamehawk96@yahoo.com 2009-06-02 20:27:45 --- It doesn't have to be a swirly, simply move winamp off the the desktop into another one (by dragging) and it disappears.
It seems that doing a swirly causes it, but it only is a problem when the equalizer or the playlist is attached to the winamp client. In this case, moving the group causes the winamp agent to jump aroun,d which lets it jump off of the screen whether it be the top, left, or right edge (winamp 2.79)
http://bugs.winehq.org/show_bug.cgi?id=15346
RD frail.knight@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |frail.knight@gmail.com
--- Comment #10 from RD frail.knight@gmail.com 2009-07-21 22:57:23 --- Confirming still an issue using Winamp 5.56 along with wine 1.1.26.
http://bugs.winehq.org/show_bug.cgi?id=15346
sub.mesa@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sub.mesa@gmail.com
--- Comment #11 from sub.mesa@gmail.com 2009-09-17 14:45:14 --- Confirming this bug is still present with vanilla wine 1.1.29 and Winamp 5.56. Moving the windows too much will make them invisible, possibly located off-screen. There are alot of fixme's in the terminal output, but i guess someone more qualified should analyse why winamp is behaving this way.
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #12 from Daniel flamehawk96@yahoo.com 2009-09-17 16:39:56 --- Created an attachment (id=23639) --> (http://bugs.winehq.org/attachment.cgi?id=23639) output for 'disappearance'
this is the output generated when winamp is taken out of the screen then suddenly 'disappears'
http://bugs.winehq.org/show_bug.cgi?id=15346
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
--- Comment #13 from NSLW lukasz.wojnilowicz@gmail.com 2009-10-04 10:39:54 --- When I select Winamp window then press Alt+F7 (Strg+F7) and then move Winamp window with mouse I don't experience this bug. I can even move this window to another desktop. Winamp window undergoes wobbly windows effect when compiz enabled. All standard winamp skins behave exactly the same.
If I press left mouse button on Winamp window and try to move it with mouse I experience bug mentioned in first post. Wobbly windows effect doesn't apply to that window at all.
I think it's important tip to solve this issue. I also think that title of this bug should be changed to something like "Winamp window disappears when dragged with mouse"
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #14 from NSLW lukasz.wojnilowicz@gmail.com 2009-10-04 11:38:20 --- Another way is to mark Allow DirectX apps to stop the mouse leaving their window and unmark Allow the window manager to control the windows This way is way worse than above but it allows me to drag Winamp window with mouse
http://bugs.winehq.org/show_bug.cgi?id=15346
Peter Dons Tychsen donpedro@tdcadsl.dk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |donpedro@tdcadsl.dk
--- Comment #15 from Peter Dons Tychsen donpedro@tdcadsl.dk 2009-10-05 12:23:11 --- I have debugged the problem, and found the following:
1) Winamp itself controls the movement of the windows using DeferWindowPos(). 2) This is translate to a XReconfigureWMWindow in x11drv.
This is the problem. Many (most/all) window managers interfere with calls like this. The easiest way to see this problem is too try and move Winamp out of the window (partially). This is not allowed by the WM.
The solution is to disable the WM while doing XReconfigureWMWindow() or similar operations, so that the WM does not interfere. This fixes the problem you have filed, plus it stabilises and improves the movement of Winamp.
The following patch fixes the problem by doing just that.
Thanks,
/pedro
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #16 from Peter Dons Tychsen donpedro@tdcadsl.dk 2009-10-05 12:24:39 --- Created an attachment (id=23944) --> (http://bugs.winehq.org/attachment.cgi?id=23944) Disables the WM while moving windows
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #17 from NSLW lukasz.wojnilowicz@gmail.com 2009-10-05 13:40:07 --- (In reply to comment #16)
Created an attachment (id=23944)
--> (http://bugs.winehq.org/attachment.cgi?id=23944) [details]
Disables the WM while moving windows
Is it patch or hack and will you send this so we could see it in next Wine releases?
I think someone could set component to x11drv and add patch in Keywords
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #18 from Daniel flamehawk96@yahoo.com 2009-10-05 13:42:55 --- (In reply to comment #16)
Created an attachment (id=23944)
--> (http://bugs.winehq.org/attachment.cgi?id=23944) [details]
ive tried the patch, and don't see winamp disappearing in metacity as easily, however it does still jump around when it is moved.
this time i have to try alot harder in order to make it disappear, this involves near moving winamp to the top-right or top-left edge of the screen and by moving, i mean moving it everywhere to try to get the bug to happen
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #19 from Peter Dons Tychsen donpedro@tdcadsl.dk 2009-10-05 15:07:28 ---
Is it patch or hack and will you send this so we could see it in next Wine releases?
Its a patch and i have already sent it. It is not only this bug that triggers it. Any application who calls SetWindowPos can experience problems without this patch.
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #20 from Peter Dons Tychsen donpedro@tdcadsl.dk 2009-10-05 15:15:23 ---
ive tried the patch, and don't see winamp disappearing in metacity as easily, however it does still jump around when it is moved.
Yes i see it. That is a separate and unrelated bug i think. File a new bug for that.
this time i have to try alot harder in order to make it disappear, this involves near moving winamp to the top-right or top-left edge of the screen and by moving, i mean moving it everywhere to try to get the bug to happen
Yes. This happens in the top and bottom part of the window. I think it is caused by the "jumping around" you mentioned above. This can cause the window to be placed above or below the screen which is not supported by the WM. I think this also relates to a WM bug.
/pedro
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #21 from Peter Dons Tychsen donpedro@tdcadsl.dk 2009-10-05 15:20:50 --- New patch (TRY 2) sent, as the first one had a small bug.
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #22 from Peter Dons Tychsen donpedro@tdcadsl.dk 2009-10-05 15:21:19 --- Created an attachment (id=23948) --> (http://bugs.winehq.org/attachment.cgi?id=23948) TRY2 of patch
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #23 from Alexandre Julliard julliard@winehq.org 2009-10-05 16:28:37 --- You can't do that sort of thing. If you really don't want the window manager to control the windows there's an option for it, but you can't have it both ways.
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #24 from Peter Dons Tychsen donpedro@tdcadsl.dk 2009-10-05 21:39:52 ---
You can't do that sort of thing. If you really don't want the window manager to control the windows there's an option for it, but you can't have it both ways.
I am not sure i agree. Everywhere i looked they referred to "override_redirect" as being *the way* to control this. And doing so is totally valid.
The xlib manual is very clear on this:
"To control window placement or to add decoration, a window manager often needs to intercept (redirect) any map or configure request. Pop-up windows, however, often need to be mapped without a window manager getting in the way. To control whether an InputOutput or InputOnly window is to ignore these structure control facilities, use the override-redirect flag."
I think this says it all...
http://tronche.com/gui/x/xlib/window/attributes/override-redirect.html
I also checked the source code for Metacity, which only confirmed my findings. Notes and code to support the statement above was in place.
Please consider this, as it makes some apps look so much better.
Thanks,
/pedro
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #25 from Daniel flamehawk96@yahoo.com 2009-10-05 22:18:50 --- there is a problem with both alternatives.... it will drive you nuts in compiz (ubutnu, gnome)
with this option, winamp runs in every desktop which is extremely annoying
the patch lets you see winamp in the taskbar, while the built-in feature does not.
though its pretty much the same in every other aspect
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #26 from Peter Dons Tychsen donpedro@tdcadsl.dk 2009-10-07 19:44:19 --- There is a bug in the X11 mouse code which is affecting this problem. The mouse code is using the cached values "whole_rect" and "client_rect". These are not updated at the correct time, so the calculations end up bad. This causes the "jumping around" that you are seeing.
http://bugs.winehq.org/show_bug.cgi?id=15346
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|All |Other
--- Comment #27 from Austin English austinenglish@gmail.com 2012-02-23 15:26:24 CST --- Removing deprecated 'All' Platform.
http://bugs.winehq.org/show_bug.cgi?id=15346
Rafal Stanilewicz washuu@eastnews.com.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |washuu@eastnews.com.pl
--- Comment #28 from Rafal Stanilewicz washuu@eastnews.com.pl 2012-03-28 08:37:48 CDT --- I could NOT reproduce this on wine 1.4.0 and Ubuntu with Unity. But Unity perhaps is not very representative sample...:-)
http://bugs.winehq.org/show_bug.cgi?id=15346
Mina 842mono@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |842mono@gmail.com
--- Comment #29 from Mina 842mono@gmail.com 2013-08-15 03:12:25 CDT ---
New patch (TRY 2) sent, as the first one had a small bug.
How do I use the patch?
http://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #30 from Bruno Jesus 00cpxxx@gmail.com 2013-08-15 08:18:44 CDT --- (In reply to comment #29)
How do I use the patch?
Please see http://wiki.winehq.org/Patching
If you have trouble, please use the forum to get help.
http://bugs.winehq.org/show_bug.cgi?id=15346
hanska2@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hanska2@luukku.com
--- Comment #31 from hanska2@luukku.com --- What's the bug status?
Not so long ago with some 1.7 series wine I had this issue. When I drag wine close to border, it went to taskbar and also the dragging wasn't smoothly animated.
I retry few other bugs now and tried this and I couldnt see it behaving like it.
I don't know why.
Kde updates have fixed it? or Wine? I have mint17 now in use. Before I had kubuntu.
wine 1.7.22
https://bugs.winehq.org/show_bug.cgi?id=15346
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #32 from super_man@post.com --- I just recently tried this with 1.7.48 and the issue is still there (kde).
https://bugs.winehq.org/show_bug.cgi?id=15346
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=15346
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #33 from winetest@luukku.com --- (In reply to Arkadiusz Piekarz from comment #3)
Winamp windows indeed disappear, but only if you try to move them outside of the desktop. Happens both in Metacity and Compiz. The system monitor shows that Winamp still works, but its windows can't be seen.
Winamp 5.541, Wine 1.1.5, Ubuntu 8.04, Ati Radeon x2300, 8.9 official drivers.
Sounds like bug 26225.
https://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #34 from winetest@luukku.com --- I just tested this. I changed winamp skin to the original and restared winamp. Moved the window next to screen border and the application vanishes.
wine 2.0.rc3.
https://bugs.winehq.org/show_bug.cgi?id=15346
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|download | CC| |gabrielopcode@gmail.com
--- Comment #35 from Gabriel Ivăncescu gabrielopcode@gmail.com --- (In reply to Peter Dons Tychsen from comment #26)
There is a bug in the X11 mouse code which is affecting this problem. The mouse code is using the cached values "whole_rect" and "client_rect". These are not updated at the correct time, so the calculations end up bad. This causes the "jumping around" that you are seeing.
I filed a separate bug for this problem, which I plan on fixing. See: https://bugs.winehq.org/show_bug.cgi?id=46309
I think we should really just be using the root-relative coordinates instead of window-relative here (so problem is on X server side, not ours).
https://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #36 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 63094 --> https://bugs.winehq.org/attachment.cgi?id=63094 Query the X server for the actual rect of the window before unmapping it
Here's an attempt at fixing this without disabling WM integration (which obviously isn't desirable, else people would disable the option themselves).
The problem seems to be the unmap itself (that's why it disappears). Currently, Wine checks if the rect is outside the screen and was inside of it before, and then unmaps it in this case. But the WM can interfere with this and the actual rect may not be outside after all.
This patch just queries the X server for the window's rect in this case, which seems to solve the problem for me.
Please test it if you can, I hope it doesn't break anything (can't really see why but the unmapping itself is suspect to me and I don't have much experience with the X11 code).
https://bugs.winehq.org/show_bug.cgi?id=15346
Felix Zielcke fzielcke@z-51.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fzielcke@z-51.de
https://bugs.winehq.org/show_bug.cgi?id=15346
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/winex11.drv-Quer | |y_server_position
https://bugs.winehq.org/show_bug.cgi?id=15346
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #63094|0 |1 is obsolete| |
--- Comment #37 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 68411 --> https://bugs.winehq.org/attachment.cgi?id=68411 Let the Window Manager handle the off-screen window if it's managed.
Here's an updated patch that simplifies it, now that I understand a lot more about the winex11 driver code.
As a simplified overview, in general the driver callbacks have two cases: when they are handled during an X11 event, and when they're handled by a Win32 call without an event.
The distinction is important: when we are processing an X11 event, we want to sync the windows side to match what the X11 state reports (for example, if the user resizes the X11 window, we make it match on the windows side).
When we are not processing an event, we do it the other way around: we sync the X11 server state with the windows side, to match what the windows side reports. For example, if you call SetWindowPos without any event, the X11 window must obviously respond accordingly and actually move on the screen.
In this particular case, we move the window by dragging it, i.e. X11 event. *However*, the application (Winamp) calls SetWindowPos on itself outside of this, so in fact, we are *not* processing an event during that callback.
The code in question clearly has !event_type, which only runs when there's no event anyway. What the current code attempts to do is check if the window is basically "offscreen" (including multiple monitors). If so, it unmaps it (i.e. hides it).
But that's the problem, and that's why it shows up only when the windows are managed. Window Managers have their own way to deal with offscreen windows, and we should simply respect that by sending the window position as offscreen so they handle it, instead of trying to hide it ourselves. One popular example is virtual desktops or workspaces built into the WM.
So this patch simply removes the window unmapping if the window is managed, and the issue is solved.
Please note that the former patch above does exactly the same thing in this context. That is because querying the WM for the window position when we are *not* processing an event is going to always report it as on-screen (because we haven't synced it yet to the windows side that moves it off-screen). So it's kind of useless to query it.
I tested the patch and it works with both managed and non-managed modes (in winecfg).
https://bugs.winehq.org/show_bug.cgi?id=15346
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #68411|0 |1 is obsolete| |
--- Comment #38 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 68412 --> https://bugs.winehq.org/attachment.cgi?id=68412 Let the Window Manager handle the off-screen window if it's managed.
Sorry, previous patch had a dumb use-after-free error. This fixes it.
https://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #39 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Gabriel Ivăncescu from comment #38)
Would you try addressing bug 43691 too ?
Patch 194655 touches part of the code my patch does and these problems are sort of related.
https://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #40 from winetest@luukku.com --- (In reply to Rafał Mużyło from comment #39)
(In reply to Gabriel Ivăncescu from comment #38)
Would you try addressing bug 43691 too ?
Patch 194655 touches part of the code my patch does and these problems are sort of related.
he did.
https://bugs.winehq.org/show_bug.cgi?id=15346
msuhoruki@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |msuhoruki@gmail.com
--- Comment #41 from msuhoruki@gmail.com --- Hi, this problem occurs with Wine 9.18 and Winamp 2.95. I'm pretty sure it worked at some point with 9.x but I've just noticed after upgrading to 9.18. Moving Winamp with Alt+mouse works, so there's a workaround.
https://bugs.winehq.org/show_bug.cgi?id=15346
Felix Zielcke fzielcke@z-51.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|fzielcke@z-51.de |
https://bugs.winehq.org/show_bug.cgi?id=15346
--- Comment #42 from msuhoruki@gmail.com --- Issue seems to occur in Trinity desktop. In comparison Winamp does not disappear when using XFCE 4.12.