GNOME Bugzilla – Bug 480270
Trying to resize a window randomly triggers the context menu
Last modified: 2020-11-06 20:05:41 UTC
When trying to drag-resize a window, sometimes the context menu is invoked instead, and the left button will behave like the right button (with the right button still acting as right). It's generally pretty hard to remove and requires some switching around and often Alt+middle click resize to go away. Reproducibility: Very random, seems more common right after switching to a window (perhaps when the window is focused by your resize attempt?)
The Ubuntu folks seem to believe this was a deliberate feature: https://bugs.edge.launchpad.net/ubuntu/+source/metacity/+bug/147844 I don't remember (I suppose I could look it up in the ChangeLog), but does anyone know offhand?
(assuming it's the same thing)
(It isn't. I'm commenting there why not. This does still need fixing though. Can anyone reproduce?)
*** Bug 553091 has been marked as a duplicate of this bug. ***
from the other bug report: """ i'm not sure if it's the -only- time this problem occurs, but i've recently discovered that i can get it to happen 100% of the time by dragging the top of the window off the top of the screen. dragging bringing the window back causes the problem to go away. """
I'm pretty sure this was introduced deliberately by Elijah under the theory that if the title bar is not visible, then there is no way to move the window unless you know about context menus. Since some people don't, the context menu is popped up on left-click. Personally, I disagree completely; having left-click suddenly change its meaning and show a context menu is crack. A better solution would be to not allow alt-dragging to put the title bar off-screen, just like normal dragging doesn't allow it. It's a recurrent Fedora bug; here is one of them: https://bugzilla.redhat.com/show_bug.cgi?id=491413
(In reply to comment #6) > I'm pretty sure this was introduced deliberately by Elijah under the theory > that if the title bar is not visible, then there is no way to move the window > unless you know about context menus. Since some people don't, the context menu > is popped up on left-click. > > Personally, I disagree completely; having left-click suddenly change its > meaning and show a context menu is crack. +1. Users can't be expected to learn how things work if you keep changing the rules. And anyway, I think most users would learn about right-clicking _long_ before they learn how to alt-drag windows. I did notice the useful entry "Move Titlebar Onscreen" that appears in the context menu when the title is hidden. This entry does not appear when right-clicking the window-list button though, and it should. I can file a separate bug for this if you like. > A better solution would be to not allow alt-dragging to put the title bar > off-screen, just like normal dragging doesn't allow it. There are some apps which have a minimum window size that's too small for my netbook resolution, and alt-dragging the window until the titlebar is offscreen is the only way I can get to things. If you want to disallow this by default, please at least give me a gconf tunable so I can enable it again...
(In reply to comment #6) > I'm pretty sure this was introduced deliberately by Elijah under the theory > that if the title bar is not visible, then there is no way to move the window > unless you know about context menus. Since some people don't, the context menu > is popped up on left-click. Very close; just one minor correction: "...unless you know about context menus or alt-drag or alt-f7. Since some people...". > Personally, I disagree completely; having left-click suddenly change its > meaning and show a context menu is crack. A better solution would be to not > allow alt-dragging to put the title bar off-screen, just like normal dragging > doesn't allow it. How about an alternate solution that doesn't throw out the baby with the bathwater? Show the context menu on left button mouse release (not press), and only if the user hasn't exceeded the DND threshold between button press and button release. Then it'd still be a useful escape hatch for those trying to recover offscreen windows, and not get in the way of users wanting to resize windows they've moved offscreen. (I'll bump up the severity slightly since this is a commonly recurring bug report.)
(In reply to comment #7) > I did notice the useful entry "Move Titlebar Onscreen" that appears in the > context menu when the title is hidden. This entry does not appear when > right-clicking the window-list button though, and it should. I can file a > separate bug for this if you like. That entry appears for me in the context menu in both cases; what version of metacity are you running?
(In reply to comment #8) > (In reply to comment #6) > How about an alternate solution that doesn't throw out the baby with the > bathwater? Show the context menu on left button mouse release (not press), and > only if the user hasn't exceeded the DND threshold between button press and > button release. Then it'd still be a useful escape hatch for those trying to > recover offscreen windows, and not get in the way of users wanting to resize > windows they've moved offscreen. That sounds like a reasonable compromise, though I'd still argue for consistency. Either make this escape hatch always present or not at all. It's not intuitive for mouse/menu behavior to depend on title visibility. But anyway, if I just get my resize back, I'll be happy enough... :) (In reply to comment #9) > (In reply to comment #7) > > I did notice the useful entry "Move Titlebar Onscreen" that appears in the > > context menu when the title is hidden. This entry does not appear when > > right-clicking the window-list button though, and it should. I can file a > > separate bug for this if you like. > > That entry appears for me in the context menu in both cases; what version of > metacity are you running? metacity-2.26.0-1.fc11.i586 gnome-panel-2.26.0-1.fc11.i586 (perhaps window-list is to blame?)
This mis-feature is particularly irksome when working with eog or other image viewer and you want to get as much image on-screen without actually going into a full screen view, for instance, when working with multiple images at the same time. In order to reclaim the space used by the title bar and menu bars, I alt-drag the window up so that they disappear off the top of the screen. Then I resize the windows to the bottom of the screen, moving the resize widget underneath the bottom gnome panel on my display so that the status bar at the bottom of the window isn't consuming any visible screen real-estate. But now I have no way of resizing the windows horizontally, as I get the "you clearly have no idea what you're doing and need help getting this window under control" context menu that is the subject of this bug report. Please give us some alternative to hacking the source code (or switching desktop environments) to disable this feature. (It's really staggering how many developers think it's OK to make usability changes and provide no way to retain the old behavior... like the pidgin-carrier fork debacle...) Thanks.
*** Bug 613945 has been marked as a duplicate of this bug. ***
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.