Maximize vertically/horizontally doesn't work (in some apps) if configured via middle-click

Bug #1698083 reported by Daniel van Vugt
136
This bug affects 26 people
Affects Status Importance Assigned to Milestone
GTK+
Fix Released
Unknown
gnome-control-center (Ubuntu)
Confirmed
Medium
Unassigned
gtk+3.0 (Ubuntu)
Confirmed
Medium
Unassigned
mutter (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Upstream: https://gitlab.gnome.org/GNOME/gtk/issues/539

In Gnome Tweak Tool you can configure vertical maximizing for:
  Windows > Titlebar Actions > Middle-Click
However this feature seems to get ignored in Wayland sessions (it just maximizes fully instead). It only works correctly in Xorg Gnome sessions.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: gnome-shell 3.24.2-0ubuntu6
ProcVersionSignature: Ubuntu 4.10.0-22.24-generic 4.10.15
Uname: Linux 4.10.0-22-generic x86_64
ApportVersion: 2.20.5-0ubuntu4
Architecture: amd64
Date: Thu Jun 15 14:46:04 2017
DisplayManager: lightdm
InstallationDate: Installed on 2017-05-03 (43 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170502)
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
In , adam (adam-redhat-bugs-1) wrote :

Description of problem:
I have focus-follows-mouse and no-raise-on-click. Under X, I can click on a title bar and the window raises. Under Wayland, this does not work for Gnome windows.

Version-Release number of selected component (if applicable):
gnome-shell-3.20.2-1.fc24.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Turn off click to raise
2. Click on titlebar

Actual results:
No raise

Expected results:
Raise

Additional info:
This works fine with xterm and other X windows in Wayland. Super-Click still raises.

Revision history for this message
In , ofourdan (ofourdan-redhat-bugs) wrote :

I wonder if this related to CSD, because with CSD mutter does not own the titlebar (it's all managed by the client) and under Wayland clients cannot manipulate the stack by themselves.

Revision history for this message
In , ofourdan (ofourdan-redhat-bugs) wrote :

Humm, indeed, if you turn off "raise-on-click", the client cannot raise itself but that seems pretty much to be expected.

Revision history for this message
In , ofourdan (ofourdan-redhat-bugs) wrote :

Note the lengthy description of that option which make it very clear that this option should not be changed:

  "Setting this option to false can lead to buggy behavior, so users are strongly
   discouraged from changing it from the default of true. Many actions (e.g.
   clicking in the client area, moving or resizing the window) normally raise the
   window as a side-effect.

   Setting this option to false, which is strongly discouraged, will decouple
   raising from other user actions, and ignore raise requests generated by
   applications. See http://bugzilla.gnome.org/show_bug.cgi?id=445447#c6.

   Even when this option is false, windows can still be raised by an
   alt-left-click anywhere on the window, a normal click on the window
   decorations, or by special messages from pagers, such as activation requests
   from tasklist applets. This option is currently disabled in click-to-focus
   mode.

   Note that the list of ways to raise windows when raise_on_click is false does
   not include programmatic requests from applications to raise windows; such
   requests will be ignored regardless of the reason for the request. If you are
   an application developer and have a user complaining that your application
   does not work with this setting disabled, tell them it is _their_ fault for
   breaking their window manager and that they need to change this option back to
   true or live with the "bug" they requested."

So, considering this very explicit warning and given that this is not possible to have this option working in Wayland (by design and on purpose, clients cannot manipulate the window stacking in Wayland), my take is that we should simply ignore this option under Wayland.

I have filed a bug and posted a patch upstream in GNOME bugzilla for this.

Revision history for this message
In , adam (adam-redhat-bugs-1) wrote :

Thanks for the investigation! I will follow the upstream bug.

Revision history for this message
In , adam (adam-redhat-bugs-1) wrote :

Here is a summary of the upstream bug:

- wayland doesn't (yet) implement a protocol for a client to ask its window to be raised or lowered
- with client-side decorations, clients are responsible (through GDK) to raise or lower themselves
- so for wayland right now, there is no way to have a title bar click raise a window if click-to-raise is turned off
- BUT! even if click-to-raise is turned on, the functionality of middle-click to lower is also broken (this is action-middle-click-titlebar, configurable with GNOME Tweaks)

Can extending the xdg-shell protocol to add raise/lower commands (and implementing in GDK) be considered a wayland-as-default blocker in Fedora? This is a regression though not in the default GNOME settings.

Revision history for this message
In , ofourdan (ofourdan-redhat-bugs) wrote :

(In reply to Adam Goode from comment #5)
> [...]
>
> Can extending the xdg-shell protocol to add raise/lower commands (and
> implementing in GDK) be considered a wayland-as-default blocker in Fedora?
> This is a regression though not in the default GNOME settings.

Not my call, but I hardly see how this could be a blocker to have Wayland by default.

If someone is willing to ignore the very explicit warning in the option description (comment #3), then the same person would likely be able to switch back to X11 if that's what (s)he really means.

Revision history for this message
In , adam (adam-redhat-bugs-1) wrote :

This is an issue even when not using no click-to-raise. action-middle-click-titlebar is also broken.

Revision history for this message
In , rhbz (rhbz-redhat-bugs) wrote :

It's not just CSD. Another problem resulting from Wayland not allowing clients to raise or lower themselves is that many desktop notification actions are now no-ops. For example, clicking on Evolution's "You have # new messages" notification used to raise the message list window. Gnome-terminal's command-completed notification used to raise the window that just finished. Now both just dismiss the notification.

(Or should this be a new bug?)

Revision history for this message
In , jgotts (jgotts-redhat-bugs) wrote :

I can confirm that I can no longer lower windows after upgrading from Fedora 24 to Fedora 25. This is a serious problem for me, as I've been doing this in Linux for 22 1/2 years (since May 1994). My dconf-editor action-middle-click-titlebar setting is and continues to be 'lower'. I frankly don't care what mouse button or keystroke I need to use to lower windows, but this functionality has to be present for the desktop to be usable if you use auto raise. One of the reasons I deleted Windows entirely over two decades ago was that I despised click-to-focus.

How do I undo whatever Fedora 25 did?

Thanks!

Revision history for this message
In , adam (adam-redhat-bugs-1) wrote :

You should still be able to go back to X11 under Fedora 25. The solution is to implement the missing functionality in the wayland xdg-shell protocol.

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-shell/xdg-shell-unstable-v6.xml

Revision history for this message
In , jgotts (jgotts-redhat-bugs) wrote :

Switching back to X11 fixed the issue.

Perhaps this should be a separate bug but azureus really exhibits the bugs/missing functionality in Wayland:

1) The right mouse button menu pops up in a random location to the upper left of the screen and is corrrupted. It is impossible to do the show details operation, which is about the most common user interaction with azureus.

2) When you have more torrents than you can fit in the viewport, there is supposed to be a scrollbar. With Wayland it is missing. At least part of one torrent in your list is cut off, but it's impossible to know how many are cut off because there is no scrollbar.

3) The tabs at the bottom of the screen General, Sources, Peers, etc., are completely missing. This functionality is critical to use azureus.

4) Simply scroll up and down a few times with your mouse's wheel. The viewport gets horribly corrupted quite easily.

I have nothing against Wayland, but even though it's taken many, many years to arrive on the scene, it still isn't ready for production. To be honest, azureus is a crappy app, but I've been using it for a decade. It does what I need it to do. Since it's written in Java it puts the graphical environment through its paces and it's great at finding implementation bugs.

Revision history for this message
In , jgotts (jgotts-redhat-bugs) wrote :

5) The bottom area where you can set bandwidth constraints is missing with Wayland. This is critical in the office if you need to download a large torrent but you have a shared environment and you can't kill everybody else.

Revision history for this message
In , adam (adam-redhat-bugs-1) wrote :

Yes, please file separate bugs for these Azureus issues.

Revision history for this message
In , lars (lars-redhat-bugs-1) wrote :

(In reply to John Gotts from comment #11)
> Switching back to X11 fixed the issue.

How is this done? Not being able to use middle-click is very annoying, so I want to switch...

Revision history for this message
In , adam (adam-redhat-bugs-1) wrote :

You can follow along on the gnome bug:
https://bugzilla.gnome.org/show_bug.cgi?id=767967

Revision history for this message
Daniel van Vugt (vanvugt) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-shell (Ubuntu):
status: New → Confirmed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Seems to have started working in the past week or so. :)

Changed in gnome-shell (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I take it back. It works randomly, sometimes.

Possibly related to Gnome Tweak Tool > Windows > Titlebar Actions, but that does not seem to do what it's meant to reliably either.

Changed in gnome-shell (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Aha! It appears this feature only works in Xorg sessions ("Ubuntu") and not in "Ubuntu on Wayland" sessions.

summary: - Vertically maximize on middle button click
+ Vertically maximize on middle button click does not work in Wayland
+ sessions
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: Vertically maximize on middle button click does not work in Wayland sessions

OK, so there are a few steps to fixing this bug:

1. sudo apt install gnome-tweak-tool
2. Gnome Tweak Tool > Windows > Titlebar Actions > Middle-Click = Toggle Maximize Vertically
3. Log in using Xorg ("Ubuntu") for it to work (not "Ubuntu on Wayland").

Step #3 sounds like an obvious bug. But #2 is seemingly also a bug because it interprets the middle click anywhere on the titlebar -- clicking on the maximize button is not considered a special area.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

It appears all middle-click titlebar actions don't work when in a Wayland session.

summary: - Vertically maximize on middle button click does not work in Wayland
- sessions
+ Middle-click titlebar actions don't work in Wayland sessions
description: updated
Jeremy Bicha (jbicha)
tags: added: wayland
summary: - Middle-click titlebar actions don't work in Wayland sessions
+ Middle-click titlebar actions (like maximizing vertically) don't work in
+ Wayland sessions
Changed in gnome-shell (Ubuntu):
importance: Wishlist → Medium
Changed in mutter (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: Middle-click titlebar actions (like maximizing vertically) don't work in Wayland sessions

Actually this bug is only GTK apps on Wayland, so -> https://bugzilla.gnome.org/show_bug.cgi?id=746273

It works in non-GTK apps like Chromium.

Changed in gtk+3.0 (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
description: updated
Changed in gtk:
importance: Unknown → Wishlist
status: Unknown → Confirmed
tags: added: session
tags: added: wayland-session
removed: session
Revision history for this message
In , bcotton (bcotton-redhat-bugs) wrote :

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Revision history for this message
In , bcotton (bcotton-redhat-bugs) wrote :

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Revision history for this message
sojusnik (sojusnik) wrote :

I'm using Ubuntu 17.10 and this bug is still present with Xorg AND Wayland.

Apps with a "normal" GTK titlebar (the narrow one), like Firefox, are working according to the settings in Gnome Tweak. So a double- or middle-click on the titlebar maximizes the window f.i. vertically. But when an app has a "Gnome" titlebar (the broad one), f.i. Gedit, then the window is always maximized fully, not only vertically or horizontally.

You can download a screencast of this bug here: https://mega.nz/#!j5BSjaSL!o7E3Kuf061sJQ_tUukpe-3Tf4JTi7NExB3uI-z_ijX4

It shows the behavior of different apps, GTK and QT, with different titlebars:

Deluge (GTK): works
Qpdfview (QT): works
LibreOffice (GTK): works
Gnome Tweak: fails
Gedit: fails

Can somebody confirm this?

Would be great to have a fix soon, since this bug is around for years!

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Yes I can confirm that. But I think it should be discussed in a different bug report.

Revision history for this message
sojusnik (sojusnik) wrote :

Why is this another bug?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Because middle click actions do work in Xorg sessions, and only fail in Wayland. If you find something is broken in a Xorg session then it is not this bug.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Sorry, I was wrong.

It seems the bug is in GTK's titlebar logic. For Xorg sessions that's only used in "modern" apps with the thick headerbar. For Wayland sessions, that's used in all apps.

Revision history for this message
Joseph Maillardet (jokx) wrote :

Observation on Ubuntu 18.04 :
- All work good on Xorg session
- Problem only affect Wayland session
- Classic windows with traditional decoration (chromium, pidgin, inkscape, ...) accept middle-click action
- GTK3 apps with Headerbar decoration who use CSD (Client Side Decoration) ignores middle-click
- Don't know why, but Evolution 3.28.1-2 ignores middle-click too (but have traditional decoration !)

Freedesktop talk about that since December 2016 : https://lists.freedesktop.org/archives/wayland-devel/2016-December/thread.html#32028

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

We know it's broken (and more so in Wayland sessions). For more up to date information, please see the upstream bug instead:

  https://bugzilla.gnome.org/show_bug.cgi?id=746273

That's where any fix will occur first.

Changed in gtk:
status: Confirmed → Expired
Revision history for this message
sojusnik (sojusnik) wrote :

Please change it to "confirmed". That's still a relevant issue.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

"Expired" is a misnomer. It just moved to https://gitlab.gnome.org/GNOME/gtk/issues/539

Since we can't change that status, and shouldn't, I have just removed the gtk task. See the above link instead.

no longer affects: gtk
description: updated
summary: - Middle-click titlebar actions (like maximizing vertically) don't work in
- Wayland sessions
+ Middle-click titlebar actions (like maximizing vertically) don't work
+ (for all apps in Wayland sessions, and some apps in Xorg sessions)
summary: Middle-click titlebar actions (like maximizing vertically) don't work
- (for all apps in Wayland sessions, and some apps in Xorg sessions)
+ (for all apps in Wayland sessions, and CSD apps in Xorg sessions)
tags: added: bionic cosmic
tags: removed: artful
Revision history for this message
In , bcotton (bcotton-redhat-bugs) wrote :

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 28 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

tags: removed: cosmic
Revision history for this message
In , mildred-bug.redhat (mildred-bug.redhat-redhat-bugs) wrote :

This is one of the top most wayland itches as per https://hansdegoede.livejournal.com/21944.html where it points to few other bugtrackers:

- mutter issue (opened): https://gitlab.gnome.org/GNOME/mutter/issues/602
- gtk+ issue (closed): https://gitlab.gnome.org/GNOME/gtk/issues/1895
- ubuntu issue: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1698083

Changed in gnome-shell (Fedora):
importance: Unknown → Undecided
status: Unknown → Confirmed
Changed in gtk:
importance: Undecided → Unknown
status: New → Unknown
summary: - Middle-click titlebar actions (like maximizing vertically) don't work
- (for all apps in Wayland sessions, and CSD apps in Xorg sessions)
+ Maximize vertically/horizontally doesn't work (in some apps)
no longer affects: mutter
no longer affects: gnome-shell (Fedora)
Changed in gnome-shell (Ubuntu):
status: Confirmed → Triaged
Changed in mutter (Ubuntu):
status: Confirmed → Triaged
tags: added: focal groovy
tags: removed: groovy
no longer affects: mutter
no longer affects: gnome-shell (Ubuntu)
Revision history for this message
James Lewis (james-fsck) wrote : Re: Maximize vertically/horizontally doesn't work (in some apps)

Since this bug was logged 5 years ago, and is still present... in fact it is now on a shortlist of 2 bugs that will stop my adoption of Wayland, I thought I would confirm that it is still present in Ubuntu 22.04 (development branch), at the time of writing, with Gnome 41.1.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Yeah we know. There is an upstream bug about it which was only closed *because* of lack of interest:

  https://gitlab.gnome.org/GNOME/gtk/-/issues/539

It can always be reopened by a GNOME developer.

summary: - Maximize vertically/horizontally doesn't work (in some apps)
+ Maximize vertically/horizontally doesn't work (in some apps) if
+ configured via middle-click
Changed in gnome-control-center (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Changed in gtk:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.