After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783711 - Can't move vertically maximized window
Can't move vertically maximized window
Status: RESOLVED OBSOLETE
Product: mutter
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2017-06-12 20:14 UTC by Adam Jackson
Modified: 2021-07-05 13:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
You must enter a Description for this attachment. (1006.72 KB, video/webm)
2017-06-12 20:14 UTC, Adam Jackson
  Details
wayland: Configure partially maximized toplevels with maximized state (1.14 KB, patch)
2017-06-14 17:36 UTC, Rui Matos
none Details | Review
wayland: If we have a move grab op, skip sending configure events (1.72 KB, patch)
2017-06-14 17:36 UTC, Rui Matos
none Details | Review

Description Adam Jackson 2017-06-12 20:14:49 UTC
Created attachment 353628 [details]
You must enter a Description for this attachment.

See the attached video.

% rpm -q mutter gnome-shell 
mutter-3.24.2-1.fc26.x86_64
gnome-shell-3.24.2-1.fc26.x86_64
Comment 1 Adam Jackson 2017-06-12 20:15:54 UTC
To be clear: the window does eventually move to wherever you dragged it, it just doesn't do so "live". The window sticks where it started until you release the mouse button.
Comment 2 Rui Matos 2017-06-14 17:36:05 UTC
Created attachment 353760 [details] [review]
wayland: Configure partially maximized toplevels with maximized state

We need to set the maximized xdg toplevel state even when a window is
maximized in only a single direction, otherwise the client is free to
ignore the configured geometry which doesn't work well with our
maximization constraint.
Comment 3 Rui Matos 2017-06-14 17:36:12 UTC
Created attachment 353761 [details] [review]
wayland: If we have a move grab op, skip sending configure events

If the client ignores the geometry that our constraints determine, we
aren't able to move the window as we end up continuously sending
configure events with a geometry that the client never acks.

But, if we have a move grab op, we know we're simply moving the window
so we can simply skip the configure event and work around that issue.
Comment 4 Rui Matos 2017-06-14 17:40:55 UTC
Either of these patches fixes the bug as reported but I think both are correct anyway.

The more fundamental issue of a wayland client not acking a configured geometry and causing mutter to continuously try to configure the surface remains open and needs more careful thought to fix.
Comment 5 GNOME Infrastructure Team 2021-07-05 13:43:37 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/mutter/-/issues/

Thank you for your understanding and your help.