GNOME Bugzilla – Bug 652369
Resizing windows with bottom border doesn't work when titlebar is offscreen
Last modified: 2018-01-25 07:54:01 UTC
When trying to resize modal child windows like the preferences in Eclipse, instead of allowing to drag the window corner to resize, the window properties dialog pops up instead. The same happens with the preferences window in Firefox when clicking exactly on the border. When clicking a few pixels inside, it is possible to drag resize the window. The Firefox preferences window shows the resize triangle, the Eclipse preferences window does not. So basically the problem seems to be that in Eclipse, the resize triangle is not present. Anyway it is annoying that when clicking on the window border - anywhere, not only in the window corner - the window properties dialog pops up.
(In reply to comment #0) > When trying to resize modal child windows like the preferences in Eclipse, > instead of allowing to drag the window corner to resize, the window properties > dialog pops up instead. On left click? The window menu should only appear on right clicks. The resizing problem is a duplicate of bug 644930.
On left click, yes.
That's weird - I can't reproduce with Firefox (or any other application I checked - no Eclipse here ...). We'll need more information to narrow down the problem. What distro do you use? What version of GTK+/mutter? Are you running gnome-shell or stand-alone mutter?
I am running gnome-shell on Ubuntu natty 11.04 and installed Gnome 3 from http://ppa.launchpad.net/gnome3-team/gnome3/ubuntu. GTK+ version: 3.0.11-0ubuntu1~natty1 mutter version: 3.0.2.1-0ubuntu1~build1 If I click on the border of those child windows, a right click does the same as a left click: The window menu pops up. When hovering over the border, the expected resize cursor shows.
This seems to happen reliablywhen the titlebar is off-screen. Maybe this was intentional, to make it easier to get at the menu if the titlebar is missing? Still feels very inconsistent/undiscoverable though. 1) Open terminal. Or gedit. Or google-chrome (with system-titlebar-mode enabled) 2) With alt+button1, move window so it's partially off the top of the screen 3) Attempt to resize window with bottom border, notice window menu instead of resizing.
(In reply to comment #5) > This seems to happen reliablywhen the titlebar is off-screen. Maybe this was > intentional, to make it easier to get at the menu if the titlebar is missing? Apparently yes: http://git.gnome.org/browse/mutter/tree/src/ui/frames.c#n1752
Yeah, this is a surprising and non-obvious behavior. In a pinch, users can already access this with alt-middle-button or right-clicking the frame, or alt-left to move the window somewhere (which they should have to discover to get the window into this situation in the first place, right?)
This was done by Thomas Thurman in 2007. CC'ing him. Comment from magicus on irc: "I thought that guy was going crazy, but when the titlebar is off-screen, I see it too." -- another indicator that this is non-obvious :)
Here's a short video which shows a child window in Eclipse: http://luniks.net/other/MutterResizeChildWindow.mpg Note also the odd behaviour of the resize cursor.
(In reply to comment #6) > (In reply to comment #5) > > This seems to happen reliablywhen the titlebar is off-screen. Maybe this was > > intentional, to make it easier to get at the menu if the titlebar is missing? > > Apparently yes: http://git.gnome.org/browse/mutter/tree/src/ui/frames.c#n1752 I think we should just remove this behavior... it's really confusing and unexpected - if the user wants the menu, they aren't going to know that clicking on the resize area gives them the menu, and if they don't want the menu, they don't want the menu. (Also, from a GNOME 3 perspective: a) the menu is only available on right click, and it's available from right click on all borders always b) this behavior doesn't occur for the resize grip which is the way that a user is expected to resize for apps with a resize grip)
Created attachment 189999 [details] [review] frames: Always start grab operation on left click When left-clicking the frame border with the titlebar being off-screen, rather than starting the expected grab operation the window menu was popped up. This behavior is pretty confusing, especially since the menu button was removed from the default layout, making right-clicking the only way to get to the window menu. (In reply to comment #10) > I think we should just remove this behavior... it's really confusing and > unexpected - if the user wants the menu, they aren't going to know that > clicking on the resize area gives them the menu, and if they don't want the > menu, they don't want the menu. Makes complete sense to me ...
Created attachment 190000 [details] [review] core: Remove META_CORE_IS_TITLEBAR_ONSCREEN The functionality is no longer needed outside of core/, so remove the getter. Not sure about that one - wouldn't harm keeping it around, but as it's currently unused ...
Review of attachment 189999 [details] [review]: Looks good
Review of attachment 190000 [details] [review]: Looks good to me, if we ever need it, it's easy enough to write the code again. (And the whole ui/ vs. core/ abstracted getter thing is rather dubious in my opinion.)
Attachment 189999 [details] pushed as 526bc34 - frames: Always start grab operation on left click Attachment 190000 [details] pushed as b533ad2 - core: Remove META_CORE_IS_TITLEBAR_ONSCREEN I'll leave the bug open for now, as I'm not sure the problem is fixed (though it might be an SWT problem now) - I've not been able to reproduce the problem with attached dialogs where the parent's titlebar is onscreen (as in the video in comment 9). But then I only tested with "normal" GTK+ apps ...
I have the exact same with Firefox, with the difference that there is this rectangle in the lower right corner that when left clicked on, you have the normal resize behaviour.
Nobody complained for many years, lets assume the patches that landed fixed the issue.