http://bugs.winehq.org/show_bug.cgi?id=20865
Summary: Steam login window jumps around the screen when moved Product: Wine Version: 1.1.33 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: austin.lund@gmail.com
When running steam in Wine, at login screen if you move the window around, it appears to jump across the screen in a jerky manner, especially if the cursor is moved quickly.
A trace using WINEDEBUG='+tid,+event,+x11drv,+win,+relay' (attached) shows that sometimes the X11 driver is getting ConfigureNotify messages after the window has moved but they seem to contain the wrong values for the position on the window. Sometimes the window is moved by the ConfigureNotify handler back to where it was originally, just for Steam to move it again.
It is possible to see this if you parse the log with: grep -E 'win:SetWindowPos|x11drv:sync_window_position|event:X11DRV_ConfigureNotify'
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #1 from Austin Lund austin.lund@gmail.com 2009-11-28 22:58:03 --- Created an attachment (id=24998) --> (http://bugs.winehq.org/attachment.cgi?id=24998) WINEDEBUG='+tid,+event,+x11drv,+win,+relay' log
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 2009-11-29 23:38:23 --- What Window Manager are you using?
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #3 from Austin Lund austin.lund@gmail.com 2009-11-30 02:08:00 --- (In reply to comment #2)
What Window Manager are you using?
metacity
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #4 from Austin Lund austin.lund@gmail.com 2009-12-01 06:20:03 --- Created an attachment (id=25032) --> (http://bugs.winehq.org/attachment.cgi?id=25032) Test program showing bug
This simple test program also shows the bug. In particular setting WINEDEBUG=+win and grepping for SetWindowPos (and the word "after") shows calls to SetWindowPos and some are in reverse order. The reversed ones also have different flags set.
Interestingly, when I increase the timer interval, eventually it goes away.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #5 from Austin Lund austin.lund@gmail.com 2009-12-08 17:57:38 --- Well, I cannot recreate this on another system with 1.1.34 and different hardware (but OS wise, identical). Perhaps it is a bug in the X driver for my graphics card?
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #6 from Austin Lund austin.lund@gmail.com 2009-12-08 18:02:12 --- Wait. Spoke too soon. It seems that on the other (newer) hardware, it just happens much less often.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #7 from Austin Lund austin.lund@gmail.com 2009-12-08 22:06:28 --- After a bit of playing around, I can recreate this by running a few 'cat /dev/zero > /dev/null' then running wine and the test program.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #8 from Vincent Povirk madewokherd@gmail.com 2009-12-14 00:41:57 --- I wasn't on #wine-devel when you asked about this so I'll have to settle for writing what I know or can easily look up on the bug. :(
Wine's windowing system is odd in that it's controlled by two different servers: X and the wineserver. The position stored in wineserver is what programs see, and SetWindowPos actually updates BOTH positions (see set_window_pos and X11DRV_WindowPosChanged).
As you may have noticed, the ConfigureNotify event calls SetWindowPos (see the X11DRV_ConfigureNotify function).
Now, here's the fun part. We get a ConfigureNotify event every time the window moves, no matter who caused it. We ignore those events if the position we get matches the wineserver position.
And here's the really fun part. If we are behind in processing ConfigureNotify events, we may get a notify event for a PREVIOUS position, causing us to move the window BACK to that position. If we get two ConfigureNotify events in a row, for the same window, we will discard the old one (see merge_events), but that is no guarantee that the event we are processing is the most recent.
Unfortunately, I don't think there's any way to tell whether an event is due to Wine's configure request or something else.
http://bugs.winehq.org/show_bug.cgi?id=20865
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #9 from Vincent Povirk madewokherd@gmail.com 2009-12-14 00:45:26 --- Whoops, sorry, the decision of whether to move the window on a ConfigureNotify is based on x11drv's stored position for the window, not the wineserver position. Still, that doesn't change the rest of the analysis.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #10 from Dmitry Timoshkov dmitry@codeweavers.com 2009-12-14 06:27:36 --- I'm just curious, does the hack attached to the bug 9802 help?
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #11 from Austin Lund austin.lund@gmail.com 2009-12-14 22:30:42 --- (In reply to comment #10)
I'm just curious, does the hack attached to the bug 9802 help?
I just tried it and it does not help. Exactly the same behaviour with the patch.
http://bugs.winehq.org/show_bug.cgi?id=20865
Daniel Stiefe1maier caliga@arcor.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |caliga@arcor.de
--- Comment #12 from Daniel Stiefe1maier caliga@arcor.de 2010-02-19 11:42:04 --- TeamViewer 5 is affected by the same problem in at least two ways:
a) The connection window that shows your partner's desktop, is resized a few times directly after creation. Sometimes it then stays at a wrong size (about 100x50 pixel, which is rather silly...)
b) Widgets. (Select 'Chat' or 'Conference call' from the audio/video menu for example) They don't have a 'native' window title bar and use SetWindowPos when dragged. On my system, they jump arround like crazy.
Things to increase probability of unwanted behaviour: - stress (like cat /dev/zero > /dev/null) - having compositing enabled (and some crazy compositing-toys - allow window manager to control the window (winecfg)
On KDE at least, allowing the window manager to control the window leads to more WM_SIZE messages, when the connection window is initially created and resized. Is that because of what Vincent explained, or is it an additional KDE oddity?
I'll try the patch from bug 9802 next week and report...
So, in general, all applications that often do SetWindowPos in a short time, are affected by this problem.
Suggestion: Would it be possible to have a list with pending ConfigureNotify events? (Or more exactly: a list of coords, for which we did configure requests, but did not receive ConfigureNotify events so far) Then it should be possible to distinguish between Wine's own configure requests and others!?
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #13 from Vincent Povirk madewokherd@gmail.com 2010-02-19 12:44:32 --- There's no guarantee that the window manager will respond to all or any of our configure requests, and they're free to give a different size or location than what we ask for.
http://bugs.winehq.org/show_bug.cgi?id=20865
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winex11.drv
--- Comment #14 from Vincent Povirk madewokherd@gmail.com 2010-06-05 12:15:39 --- If we could defer ConfigureNotify processing until we know the window manager has processed any configure requests we've made, that would probably solve this bug. However, the X protocol gives us no way to figure that out.
If we could send some sort of request to the window manager that we can be sure it will respond to, we could do that after making any configure requests. When we get the reply, we'd know the window manager has processed the configure request.
We could abuse _NET_REQUEST_FRAME_EXTENTS for this purpose, if the window manager supports it.
http://bugs.winehq.org/show_bug.cgi?id=20865
Alexey Loukianov mooroon2@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #15 from Alexey Loukianov mooroon2@mail.ru 2010-06-17 03:55:29 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=20865
Alexey Loukianov mooroon2@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mooroon2@mail.ru
--- Comment #16 from Alexey Loukianov mooroon2@mail.ru 2010-06-17 04:09:23 --- Still happens with the "New UI" version of Steam + wine-1.2-rc3.
The bug behavior had slightly changed: now the window don't "jump" during the move itself, but it jumps in the same direction it was moved for about twice the distance of the original move.
http://bugs.winehq.org/show_bug.cgi?id=20865
Colin Wetherbee cww@denterprises.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cww@denterprises.org
--- Comment #17 from Colin Wetherbee cww@denterprises.org 2010-06-20 02:38:39 --- (In reply to comment #16)
Still happens with the "New UI" version of Steam + wine-1.2-rc3.
And wine-1.2-rc4.
The bug behavior had slightly changed: now the window don't "jump" during the move itself, but it jumps in the same direction it was moved for about twice the distance of the original move.
I am seeing this behavior, too... not just for the Steam login window, but for all Steam windows. It happens on about 70% of the attempts for me.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #18 from Austin Lund austin.lund@gmail.com 2010-06-21 19:43:28 --- What I don't get is why SetWindowPos needs to be called twice. From what I can gather in the code, it goes something like this:
Call to SetWindowPos() wineserver set_window_pos request is sent and updates x11drv position request sent to X server to move window ConfigureNotify event received (asynchronously) SetWindowPos() called with XEvent window information
If the X server's window position doesn't match that of the x11drv then clearly this will go back and forwards until they do agree. Why is there the need to recursively call SetWindowPos? Surely SetWindowPos should just set the x11drv position and then the driver just does it's thing. If the window manager doesn't like the new position then the driver should try it's best to fix things up and send WM_WINDOWPOSCHANGED, etc. if the size doesn't match what was requested.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #19 from Vincent Povirk madewokherd@gmail.com 2010-06-21 20:40:19 --- The message processing and wineserver calls reflect the way this works on Windows. Windows is synchronous. The Windows application needs to have immediate control over the window position. The WM_WINDOWPOSCHANGING and related messages must be processed BEFORE SetWindowPos returns. The new position is really determined by the arguments to WM_WINDOWPOSCHANGING when it returns. Thus, the program has complete and immediate control over its position.
You can think of user32 and wineserver has having its own self-contained windowing system that correctly imitates the Windows windowing system. This is necessary for compatibility with Windows programs.
X is completely different. In X, we ask the window manager for a new position, and it moves/resizes our window when it gets around to it. Or not. And not necessarily in the way we ask. We get a notification whenever the position changes, with no indication of the reason.
X11DRV_WindowPosChanged and X11DRV_ConfigureNotify are the glue that connects the fully correct and synchronous wineserver windowing system to the asynchronous X windowing system. ConfigureNotify must call SetWindowPos when we get something not requested so that the application gets a WM_WINDOWPOSCHANGING message (which it can use to request a different position, in which case we SHOULD send another configure request) and so that the wineserver position can be updated.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #20 from Austin Lund austin.lund@gmail.com 2010-06-21 20:51:23 --- Still not sure I follow. I understand the synchronous-asynchronous issue. But why not have most of it "behind the scenes" so to say. For example, calling SetWindowPos just sets the x11drv position after sending the usual messages and sends the request to update the window position in the X server. When the ConfigureNotify event comes in it just compares with what the x11drv has and updates it as necessary sending appropriate messages to the WndProc as required instead of doing the full SetWindowPos which may put in another move request to the server.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #21 from Vincent Povirk madewokherd@gmail.com 2010-06-21 21:07:32 --- There are cases where it's appropriate for a ConfigureNotify event to result in another ConfigureWindow request. Namely, if an application handles a WM_WINDOWPOSCHANGING event by supplying a new size/position.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #22 from Vincent Povirk madewokherd@gmail.com 2010-06-21 21:30:40 --- Created an attachment (id=29062) --> (http://bugs.winehq.org/attachment.cgi?id=29062) patch: update the x11drv position from ConfigureNotify events
Does this patch improve anything?
http://bugs.winehq.org/show_bug.cgi?id=20865
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #29062|0 |1 is obsolete| |
--- Comment #23 from Vincent Povirk madewokherd@gmail.com 2010-06-21 21:46:39 --- (From update of attachment 29062) Never mind, this needs (still) more thought.
I think the x11drv position of a window (which consists of window_rect, whole_rect, and client_rect) needs to be updated in the ConfigureNotify event AND X11DRV_WindowPosChanging needs to check whether it has changed, which doesn't seem to happen for non-decorated windows like the steam window.
I think that if we check for changes based on our most recent idea of the X position of the window (either a ConfigureNotify event or a configure request), that will prevent us from making more requests from these intermediate ConfigureNotify events.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #24 from Alexey Loukianov mooroon2@mail.ru 2010-06-22 03:37:52 --- Correct me if I'm wrong: as this problem is mainly connected with the "X Window Manager <=> Wine <=> Wine App" interactions then the bug shouldn't happen when using wine's virtual desktop feature thus dropping the X Window manager out of the game?
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #25 from Austin Lund austin.lund@gmail.com 2010-06-22 06:22:52 --- (In reply to comment #21)
There are cases where it's appropriate for a ConfigureNotify event to result in another ConfigureWindow request. Namely, if an application handles a WM_WINDOWPOSCHANGING event by supplying a new size/position.
But isn't the way to do the WM_WINDOWPOSCHANGING to adjust the WINDOWPOS passed in the lParam and not to call SetWindowPos()?
The one case I can think of where this makes sense is when a non-wine based movement of the window occurs. My guess is that either X or the window manager will do this and a ConfigureNotify event will occur because of it. But surely this is a reason to update the x11drv information (and send appropriate window messages) rather than calling SetWindowPos (unless you change the WINDOWPOS structure as above, which could be handled by checking if the WndProc did that).
The heart of the issue is when this occurs:
SetWindowPos(100,100,100,100) <- from application SetWindowPos(200,200,100,100) <- from application, no ConfigureNotify ConfigureNotify(100,100,100,100) <- from first call SetWindowPos(100,100,100,100) <- from wine ConfigureNotify handler ConfigureNotify(200,200,100,100) <- from second call SetWindowPos(200,200,100,100) #Two ConfigureNotifys are joined ConfigureNotify(200,200,100,100) #Done as things are consistent.
But this will make things jump around before being done. The issue is that SetWindowPos will return then another call to SetWindowPos can be made before the window is actually moved and the ConfigureNotify event is sent. If there was a lock which blocked the second SetWindowPos call until a configure notify event occurs between the first and second SetWindowPos calls then the jumping cannot occur. And if an external ConfigureWindow call happens then this is not blocked as it's only calling SetWindowPos that takes the lock and ConfigureNotify which releases it. If the external ConfigureWindow call occurs between the two SetWindowPos calls then it will jump around, but that would happen anyway.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #26 from Alexey Loukianov mooroon2@mail.ru 2010-06-22 07:08:37 --- I had tested the issue a little bit more and found another interesting thing: if I move any of the Steam windows by pressing Alt+Space on the keyboard and selecting "Move..." from the window system menu then no jumps does happen. Also there are no jumps if I move the windows using window manager keybinding to activate the "mousedrag window move" mode (defaults to pressing Alt on the kerboard and dragging a window with a mouse, but I had it set to use Win key as the toggling modifier).
Looks like the trigger for this bug to happens with Steam is due to Steam uses undecorated windows and tries to manage the window moves itself. Don't know if this proves the discussion related to the causes of the bug or contradicts with them.
Another thing I want to mention again is that now days there are no jumps _while_ moving the Steam window but there's one big jump just after the window had been moved and the left mouse button had been released. And it is typical for window to continue moving following the mouse cursor even some more time _after_ the mouse button had been released (looks like that "left_mouse_button_up" event gets somehow posponed in favour of "mouse_move" events). Sometimes this may last for several seconds if i continue to constantly move the mouse at a not-so-fast but constant speed. It seems that this "never-ending-move" lasts as long as mouse produce a "mouse_move" events being "inside" moved Steam window. Placing some window that takes a lot of resources to redraw under the moved window increases this effect even more: I've been able to get the window continue moving after the left mouse button release for about a minute by moving "Game properties" windows over the maximized main Steam window.
Hope this will help to track the bug down.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #27 from Alexey Loukianov mooroon2@mail.ru 2010-06-22 07:14:53 --- And another finding: turning off the effect of showing the window contents while dragging in the window manager greatly reduces the probability of the "jump after the move" but don't fixes it completely. Also the behavior I had mentioned it the previous comment when a window continue to move after the mouse button release still takes place.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #28 from Vincent Povirk madewokherd@gmail.com 2010-06-22 09:12:09 --- It will probably still happen because ConfigureNotify events are still asynchronous and we process them the same way.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #29 from Alexandre Julliard julliard@winehq.org 2010-06-22 09:22:26 --- (In reply to comment #28)
It will probably still happen because ConfigureNotify events are still asynchronous and we process them the same way.
Actually we don't, there have been several fixes that should help, particularly 00b06dac85c096f20f7beed8898553166f07e6ad.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #30 from Austin Lund austin.lund@gmail.com 2010-06-22 17:49:13 --- (In reply to comment #26)
Looks like the trigger for this bug to happens with Steam is due to Steam uses undecorated windows and tries to manage the window moves itself. Don't know if this proves the discussion related to the causes of the bug or contradicts with them.
The test program which is attached does recreate how Steam's login window handles things. Note that what you are saying is exactly what happens.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #31 from Alexey Loukianov mooroon2@mail.ru 2010-06-22 17:51:42 --- (In reply to comment #30)
The test program which is attached does recreate how Steam's login window handles things. Note that what you are saying is exactly what happens.
Good to know that the testcase program still valid, thanks.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #32 from Austin Lund austin.lund@gmail.com 2010-06-22 18:23:59 --- Created an attachment (id=29075) --> (http://bugs.winehq.org/attachment.cgi?id=29075) WINEDEBUG=+win,+x11drv,+event wine a.exe 2>&1 | egrep '(event.X11DRV_ConfigureNotify|SetWindowPos.hwnd|sync_window_pos)'
Attached is the output of
WINEDEBUG=+win,+x11drv,+event wine a.exe 2>&1 | egrep '(event.X11DRV_ConfigureNotify|SetWindowPos.hwnd|sync_window_pos)'
for the two situations of no load and full load (full load being 'for t in $(seq 10); do cat /dev/urandom > /dev/null & done'). This was done with wine-1.2-rc4-70-g802c4de. Though I will note that the harsh jumping has settled down considerably since 00b06dac85c096f20f7beed8898553166f07e6ad, but the calling of SetWindowPos back to a previous location does still occur.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #33 from Austin Lund austin.lund@gmail.com 2010-06-24 06:29:55 --- I'll try and summarise what I got out of the conversation on IRC today.
The window can either be moved by wine or something external.
Currently moving the window by wine using SetWindowPos will calculate what needs to be done then store this position in the winex11.drv data structure and then sync with the X server by at some time calling XReconfigureWMWindow.
If an external move occurs, then a ConfigureNotify message is received and this needs to be passed to winex11.drv which at the moment is done by calling SetWindowPos.
Unfortunately this bug is a nasty side effect of this. If two SetWindowPos calls are performed before a ConfigureNotify event is received then the value of the ConfigureNotify coords will not match that in winex11.drv and will issue a SetWindowPos as if the window was moved from an external source. This causes the backwards moving events reported in this bug.
After a long discussion on IRC, I think I gathered that ConfigureNotify really never needs to call XReconfigureWMWindow to actually move a window. But it does need to call SetWindowPos to ensure that winex11.drv knows that a window move occurred (otherwise dependent windows will not be moved appropriately). At the moment to two things are bound together.
If there were two ways of calling SetWindowPos, the normal way and one which would do everything except call XReconfigureWMWindow then this would be enough. The ConfigureNotify handler would call the version which didn't issue a XReconfigureWMWindow. The downside to this is that the messages sent to WndProc would be doubled in most cases (i.e. WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED would be both sent twice, once from SetWindowPos and the other from the ConfigureNotify handler).
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #34 from Alexandre Julliard julliard@winehq.org 2010-06-24 06:54:45 --- (In reply to comment #33)
After a long discussion on IRC, I think I gathered that ConfigureNotify really never needs to call XReconfigureWMWindow to actually move a window. But it does need to call SetWindowPos to ensure that winex11.drv knows that a window move occurred (otherwise dependent windows will not be moved appropriately). At the moment to two things are bound together.
No, we don't reconfigure the window in response to a ConfigureNotify.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #35 from Vincent Povirk madewokherd@gmail.com 2010-06-24 09:12:41 --- I can't find anything in the code to indicate that. I believe we don't reconfigure the window if the new position is the same as the last one we requested, but this isn't necessarily the case when we get a ConfigureNotify.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #36 from Alexandre Julliard julliard@winehq.org 2010-06-24 09:44:24 --- sync_window_position is not called when event_type == ConfigureNotify, dlls/winex11.drv/window.c around line 2338.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #37 from Austin Lund austin.lund@gmail.com 2010-06-24 18:02:33 --- (In reply to comment #36)
sync_window_position is not called when event_type == ConfigureNotify, dlls/winex11.drv/window.c around line 2338.
Hmm... OK. Then my test program perhaps does not recreate the problem. I'll have to look closer at what steam is doing.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #38 from el elton@schiert.net 2010-09-12 02:12:37 CDT --- I am experiencing a problem when resizing Steam windows. The window will not be resized to the indicated size; instead it will instantly jump to a smaller/larger size upon releasing the mouse button. Is this caused by the same bug?
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #39 from Austin Lund austin.lund@gmail.com 2010-09-12 02:44:53 CDT --- (In reply to comment #38)
I am experiencing a problem when resizing Steam windows. The window will not be resized to the indicated size; instead it will instantly jump to a smaller/larger size upon releasing the mouse button. Is this caused by the same bug?
This bug is almost certainly fixed. I've noticed some other measuring style bugs which cause the window to be misplaced or wrongly sized, but I don't think they are related to this.
http://bugs.winehq.org/show_bug.cgi?id=20865
Brandon Howard FinalCrisisSX@Hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |FinalCrisisSX@Hotmail.com
--- Comment #40 from Brandon Howard FinalCrisisSX@Hotmail.com 2010-09-14 01:08:37 CDT --- (In reply to comment #39)
This bug is almost certainly fixed. I've noticed some other measuring style bugs which cause the window to be misplaced or wrongly sized, but I don't think they are related to this.
What version are you using? Development? After 10 minutes of messing around in Wine 1.3.2 (plus a patch for Starcraft 1's battle.net menus to draw properly I doubt relate to this), this bug seems to still occur if I drag with left click around the top of Steam, but does NOT occur if I drag with Alt+Left-Drag from anywhere on the window. Which do you use?
Descriptive: If I place the cursor next to the username text in the upper right hand corner (for positional reference), and move the window with a regular left click drag the right way / speed, it moves much further than I told it to when I let go of the button. Sometimes it even flies completely offscreen, never to be used again until restarted. Ive tried for quite some time now though to do this with Alt+Left-Drag, and it works just fine with no other ill effects that I see.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #41 from Austin Lund austin.lund@gmail.com 2010-09-14 01:21:26 CDT --- (In reply to comment #40)
What version are you using? Development? After 10 minutes of messing around in Wine 1.3.2 (plus a patch for Starcraft 1's battle.net menus to draw properly I doubt relate to this), this bug seems to still occur if I drag with left click around the top of Steam, but does NOT occur if I drag with Alt+Left-Drag from anywhere on the window. Which do you use?
Descriptive: If I place the cursor next to the username text in the upper right hand corner (for positional reference), and move the window with a regular left click drag the right way / speed, it moves much further than I told it to when I let go of the button. Sometimes it even flies completely offscreen, never to be used again until restarted. Ive tried for quite some time now though to do this with Alt+Left-Drag, and it works just fine with no other ill effects that I see.
There are two bugs here which makes this confusing. The original bug I described was that the window jumped back and fowards whilst being moved There is another bug which gives the window a strange offset when the mouse is released.
The jumping whilst moving is due to the SetWindowPos and ConfigureNotify thing described here and it's fixed for me in the commit that Alexandre references. The jumping on release isn't fixed for me, but is clearly separate from this issue.
http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #42 from Alexey Loukianov mooroon2@mail.ru 2010-09-15 10:01:25 CDT --- This bug was de-facto hijacked from it's original meaning: initially it was about steam windows jumping while being moving but later on that was fixed. Then another bug was noticed with similar symptoms (jumping windows) occuring _after_ the window move and left mouse button release. Some mush had been create a new bugzilla entry about it but it had never happened leading to this bugreport hijack.
http://bugs.winehq.org/show_bug.cgi?id=20865
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #43 from Juan Lang juan_lang@yahoo.com 2010-09-15 11:13:55 CDT --- Let's mark this one fixed, then. Please open a separate bug for the others.
http://bugs.winehq.org/show_bug.cgi?id=20865
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #44 from Alexandre Julliard julliard@winehq.org 2010-09-18 13:06:03 CDT --- Closing bugs fixed in 1.3.3.
http://bugs.winehq.org/show_bug.cgi?id=20865
SheeEttin sheeettin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sheeettin@gmail.com
--- Comment #45 from SheeEttin sheeettin@gmail.com 2010-10-01 01:47:34 CDT --- Bug reported re: jumping on release. It is bug 24579.
-
wine-bugs＠winehq.org