GNOME Bugzilla – Bug 333995
Window title bar hides under panel when resizing
Last modified: 2006-10-13 13:44:46 UTC
Please describe the problem: When resizing a window via on of the top edges, you can slide the title bar under the GNOME panel. I haven't found a way to get it out of there again. Steps to reproduce: 1. Run GNOME panel (horizontal) 2. Open window 3. Resize via top handles, moving as far up as you can go. Actual results: Title bar is not accessible any more. Window cannot be moved. Expected results: Resizing should be constrained to not go under the panel. Does this happen every time? Yes Other information: metacity version is 2.13.144
Hmm... not seeing this on ubuntu dapper. Same version of metacity. Are you running xcompmgr, compiz or any similar app that manages compositing? Cause they are known to disrupt these things, I've seen the bug somewhere. About being unable to move the window: you can still press <alt> and click anywhere on the window to move it.
No, I'm not doing any compositing tricks. X is X.org 7.0, btw. And the panel must be a top panel, of course (I guess that's been obvious, but just in case...)
Weird... Can you move windows below it? Either by grabbing the lower part of the title bar, or by doing <alt>-click and moving it
Just dragging the title bar the window stops at the panel, but with <meta>-drag it is indeed possible to move it behind the panel.
I can't duplicate and haven't seen any other bug reports on the matter: - Can you move all windows under the top panel or only certain ones? - Does it matter where on the titlebar you click to get it to go under the top panel? - Which theme or themes does this occur with? - How are you moving it when you get it to go under the top panel (Having <meta>-drag or <alt>-drag allow it to go under the top panel is not a bug; if you know about that feature, you know how to recover)? There are lots of ways to initiate moving/resizing windows... - Does your panel cover the entire horizontal distance of your monitor (i.e. is it set to Expand)?
Created attachment 61010 [details] Screenshot showing grip handle
1. I can't MOVE windows under the panel, only RESIZE them under there. But that goes for all windows if found so far. 2. My normal GTK+ theme is Clearlooks-Human (though not quite the upstream version), metacity is Variance; but I could reproduce with Crux (GTK) and Simple (metacity) as well. Haven't tried others, yet. 3. Only resizing, using the handle circled in the screenshot (or the one on the opposite side of the window). 4. Yes, panel is set to expand.
Oh, crap, I didn't know that part of the sides of the frame were used for a diagonal resizing. I merely had a check for whether the move/resize was started from somewhere in the titlebar... Anyway, thanks for the image that explained it all. And for taking the time to answer the questions.
This is an additional case of the constraints borkage with the titlebar (which actually isn't due to something being broken but rather having never been implemented). I'll mark as a duplicate and add a note about this case to ensure it's tested for, though. *** This bug has been marked as a duplicate of 333328 ***
The parent bug has been closed, but this issue is still not fixed in 2.15.34. Should I reopen?
Oops, yeah. I knew when I fixed the other bug that I used a hack that didn't cover this bug (there's a FIXME in metacity/src/constraints.c:constrain_titlebar_visible() that I added about this). I meant to get back to it in a couple days and fix that up, but it didn't happen. So let's reopen this one. Basically, we need to somehow record in meta_frames_button_press_event() (grep for "META_FRAME_CONTROL_RESIZE_N[EW]*") when a northward resize is selected. We need to get that information to constrain_titlebar_visible() and have it replace the window->display->grab_anchor_root_y >= window->display->grab_initial_window_pos.y; hack that currently exists. (Note that this current hack is just a funny way of checking whether the move/resize started due to a mouse click on the titlebar).
Created attachment 73730 [details] [review] Fix for this bug I don't think that the code in place was a hack at all: When a move or resize is started, in any way, meta_display_begin_grab_op is called and the display->grab_* variables are set for the current grab. It is no more than logical to use those variables in constrain_titlebar_visible, as they are available. There was something missing however: whether or not the user started the grab op by clicking on the title bar is only relevant for a MOVE op. This patch adds this test. As a result, it is no longer possible to move the title bar under the panel UNLESS it is a move op that started by clicking somewhere below the title bar. Patch has been tested for the testcase described here, as well as with ALT-F7 and ALT-F8 (neither allow hiding of title bar) and works: one can only move the title bar under the panel when ALT-clicking on the window below the title bar, resizing no longer allows hiding of title bar.
(In reply to comment #12) > one can only move the title bar under the panel when ALT-clicking on the > window below the title bar, resizing no longer allows hiding of title bar. That's not the behavior I want; I use alt-middle-click-and-drag to resize windows all the time and see no reason for not allowing the titlebar above the screen (though edge-resistance exists to allow me to line it up more easily when I want to). I also think alt+f7 should be allowed to move above the screen as well as alt+f8. The fact that alt+f8 currently doesn't allow it is a separate bug.
Created attachment 73959 [details] [review] Patch to allow hiding of title bar, except for "frame actions". Previously my understanding of the bug wasn't correct; hopefully it is now. This patch changes the code such that in constrain_titlebar_visible it is known whether or not the grab op was started as a frame action (clicking anywhere on the frame), and then only enforces the title bar to remain visible if it was a frame action. Frame actions are clicking on the frame (anywhere) without holding down the ALT key. When holding down the ALT key, the code takes a different route. As a result, you can now unrestricted move the title bar over the top of the screen (or under a top strut) even when using the keyboard (ALT-F7 or ALT-F8), or using the mouse together with ALT, but you cannot when trying to move the window by clicking on the title bar, or when resizing it by clicking anywhere on the frame (although only NW, N and NE resizements will be relevant, of course).
In general, the patch looks good. Reading over it, though, I realize I hadn't previously thought of all cases when you asked me some questions on IRC. If the user uses the window menu to start a move or resize, odds are that they got the window menu through right clicking on the titlebar, so we shouldn't allow it offscreen. Similarly, _NET_WM_MOVERESIZE messages are almost certainly going to come from clients when users click on the fake "frame" that the client has, thus we should also treat such messages as though it were a "frame action" (this affects one direct call to meta_display_begin_grab_op() as well as a call or two through meta_window_begin_grab_op()). Combining those two cases, it turns out that most calls to meta_window_begin_grab_op() should pass TRUE to meta_display_begin_grab_op() for frame_action; the only ones that this shouldn't be done for currently are those coming from handle_begin_(move|resize) in keybindings.c. So, we'll need an extra parameter in meta_window_begin_grab_op, I guess. On another note, I like Havoc's suggestion elsewhere that we start using enums instead of booleans in functions simply because it makes the code more self-documenting. You don't need to worry about that for this particular patch (since we have another boolean sitting right next to it anyway and could just handle both of them later), but I thought I'd point it out for later at least. Thanks for working on this. :)
Created attachment 74584 [details] [review] Mark menu started and _NET_WM_MOVERESIZE started grab ops as 'frame_action's too. I couldn't test the _NET_WM_MOVERESIZE stuff, but the patch seems trivial. Note that pressing ALT-F8 and then moving the mouse (as opposed to using the arrows on the keyboard) still doesn't allow to go passed any screen edge. This is not a result of constrain_titlebar_visible however; if it should be possible, then that is a seperate bug.
Looks good to me. Can you post a ChangeLog entry?
Created attachment 74607 [details] ChangeLog entry Can I close the bug? :)
Go for it. :)
Thanks, closed as FIXED. I noted you changed the ChangeLog a bit. The rationale for the changelog entries that I'm used to (learned from the gcc project) is that a changelog is merely a lookup table for file/function(/macro etc) --> date, bug# and person --> CVS diff / bugzilla discussion. Explanation of what the (new) code does is not relevant there: that should go as comments in the code (and in the bugzilla entry!). The only thing that is relevant is to add enough keywords that a grep in the ChangeLog for code related keywords (like function names) will cause the changelog entry to show up. So, * src/file.c (meta_window_struct_name): Add member_name. should be sufficient: all relevant keywords are there. There is no need to say what 'member_name' is needed for, or why it was added: that should be explained as comments in the code, really ;). Just so you know where my changelog came from. I'll assume that you want changelog entries to contain a short human explanation as well in the future. Thanks for correcting my ChangeLog entry to include the bug# :)