GNOME Bugzilla – Bug 90290
Can't move directly after roll up
Last modified: 2004-12-28 22:31:15 UTC
Try doubleclicking the title to shade the window, then keep the button pressed. Now try to move the windows with the still pressed button. Doesn't work. The other way around it works (unshading, then moving). This is just a minor inconvenience as I might want to shade a window and move it to another place "on the fly", without releasing and pressing the button again.
Batch adding GNOME2 keyword to Metacity bugs. Sorry for the spam.
Marking this up to minor just because it's a bit of a surprise, as in: "What the hell? Why won't this window move?"
Created attachment 35175 [details] [review] Don't let UnmapNotify event end the grab The (main) problem was that we would allow UnmapNotify events end the grab. This is fixed by only allowing UnmapNotify events on unshaded windows to end a grab. However, fixing that brought up another (much smaller) problem...some windows would lose focus at this point. This was because the Unmap event tried to unfocus the window, and because the Unmap event would generate FocusOut events that would try to unfocus the window. I handled this with the ignored_serials infrastructure. However, fixing this brought up one more problem in testing (which is fairly innocuous and pretty rare, but still annoying). If your double-click-on-titlebar action is shade/unshade and you are using mouse focus, and after double-clicking on a window to shade it you move off the frame to an area where another window is not below the mouse pointer, then the window you shaded MIGHT still have focus (it seemed to for emacs windows, but not for gnome-terminal ones). It appears that under these special circumstances, focusing of the no_focus_window from the LeaveNotify event does not result in a FocusOut event being generated for the emacs window/frame. (Yes, I double-checked to see whether I was just accidentally ignoring the FocusOut) That's really odd since it meant I could get more than one titlebar to appear focused. Anyway, I added a simple workaround when receiving a FocusIn on the no_focus_window (which actually makes this slightly more odd--why would a FocusIn be generated for the no_focus-window when there's no matching FocusOut generated for the emacs window?...) I'd still really like to know why no FocusOut event is generated for the emacs window that I can find; it seems that one is generated under those circumstances without this patch. But I don't see how my patch changes anything that could be related. Any ideas?
Comment on attachment 35175 [details] [review] Don't let UnmapNotify event end the grab Not a big fan of that fake_xevent hack, why not just factor out a notify_unfocus or maybe change how things work inside notify_focus so that on FocusIn we ensure that the current focus window has been focused out. Re: why you don't get FocusOut, though, I think the comment at the top of window_notify_focus() explains it - you get UnmapNotify instead. So maybe you don't need this hack with that knowledge. On the main patch: there's a reason we end the grab on UnmapNotify right - so if a window unmaps itself or gets minimized or something somehow then the grab won't be stuck... maybe we should change to be sure we end the grab when we hide the window *and* its frame? Or do we already do that? What I'm saying is that if we change whether we consider a window-frame pair to be showing we might want to end the grab. Then we could remove the "end grab on unmap" rather than having a special case in there about shaded windows.
> Re: why you don't get FocusOut, though, I think the comment at the top of > window_notify_focus() explains it - you get UnmapNotify instead. So maybe you > don't need this hack with that knowledge. I think I didn't explain it very well. Steps: 1) Set double-click-on-titlebar action to shade/unshade (this problem is not reproduceable when using keybindings to shade) 2) Set focus method to mouse 3) Open an emacs window 4) Move the emacs window to somewhere that the titlebar isn't surrounded by other windows (you want to be able to move the mouse off the titlebar onto the desktop) 5) Double click on the emacs titlebar 6) Wait...for as long as you want 7) Move the mouse from the emacs titlebar to the desktop 8) Observe that the emacs titlebar has focus, even though it shouldn't. Now, step 7 clearly isn't going to generate any Unmap events, so the comment in window_notify_unfocus() isn't relevant in this case. Any other ideas? Your other suggestions sound good. I'll look into them.
Right, but you aren't going to get FocusOut on the emacs window because it's unmapped (since it's shaded), right?
I should get a FocusOut on something (the emacs frame if nothing else). And most the time I do. For example, continuing the steps above: 9) Move the mouse back over the emacs titlebar (it still has focus, as you'd expect) 10) Move the mouse out of the emacs titlebar 11) Note that the emacs titlebar is correctly unfocused due to a FocusOut event It turns out that it's only the first time that the mouse leaves the titlebar after the double-click-to-shade that we aren't getting a FocusOut like we should. (There is something else that's weird though--we also get FocusOut events whenever the mouse _enters_ the shaded window's titlebar)
There are possible races, probably... consider that we're queuing an idle to unmap the emacs window, then setting focus to the frame with meta_display_get_current_timestamp()... so wacky stuff could happen. Maybe if you put in enough debug spew to see all the relevant calls, events, and timestamps the pattern would become clear. I'm just guessing at stuff.
I don't know if I just didn't pay attention closely enough, or if my machine at school was different, but on my home desktop and on my laptop with metacity cvs head but without any part of this patch, I can get the double-click-to-roll-up-unfocuses-too bug, meaning that this is two different bugs and that I should file a separate one for the focus issues. (One really odd thing to note however, for whenever I get around to filing that bug, is that on my laptop using metacity 2.8.6 from FC3, the double-click-to-roll-up-unfocuses-too bug does not seem to be present, so it may be something in HEAD that causes the issue...)
Created attachment 35242 [details] [review] Don't special case for shaded windows; instead check if window frame is mapped With the fix from bug 162353 to correct all the focus issues observed, this became a fairly simple one-liner. ;-)
Comment on attachment 35242 [details] [review] Don't special case for shaded windows; instead check if window frame is mapped remember that window->frame can be NULL ... if you add handling of that then this seems good.
Created attachment 35258 [details] [review] Check if window->frame is NULL first
committed.