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

[Daniel van Vugt]

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)

[adam (adam-redhat-bugs-1)]

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.

[ofourdan (ofourdan-redhat-bugs)]

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.

[ofourdan (ofourdan-redhat-bugs)]

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

[ofourdan (ofourdan-redhat-bugs)]

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.

[adam (adam-redhat-bugs-1)]

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

[adam (adam-redhat-bugs-1)]

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.

[ofourdan (ofourdan-redhat-bugs)]

(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.

[adam (adam-redhat-bugs-1)]

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

[rhbz (rhbz-redhat-bugs)]

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?)

[jgotts (jgotts-redhat-bugs)]

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!

[adam (adam-redhat-bugs-1)]

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

[jgotts (jgotts-redhat-bugs)]

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.

[jgotts (jgotts-redhat-bugs)]

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.

[adam (adam-redhat-bugs-1)]

Yes, please file separate bugs for these Azureus issues.

[lars (lars-redhat-bugs-1)]

(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...

[adam (adam-redhat-bugs-1)]

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

[Launchpad Janitor (janitor)]

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

[Daniel van Vugt (vanvugt)]

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

[Daniel van Vugt (vanvugt)]

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.

[Daniel van Vugt (vanvugt)]

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

[Daniel van Vugt (vanvugt)]

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.

[Daniel van Vugt (vanvugt)]

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

[Daniel van Vugt (vanvugt)]

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.

[bcotton (bcotton-redhat-bugs)]

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.

[bcotton (bcotton-redhat-bugs)]

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

[sojusnik (sojusnik)]

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!

[Daniel van Vugt (vanvugt)]

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

[sojusnik (sojusnik)]

Why is this another bug?

[Daniel van Vugt (vanvugt)]

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.

[Daniel van Vugt (vanvugt)]

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.

[Joseph Maillardet (jokx)]

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

[Daniel van Vugt (vanvugt)]

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.

[sojusnik (sojusnik)]

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

[Daniel van Vugt (vanvugt)]

"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.

[bcotton (bcotton-redhat-bugs)]

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.

[mildred-bug.redhat (mildred-bug.redhat-redhat-bugs)]

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

[James Lewis (james-fsck)]

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.

[Daniel van Vugt (vanvugt)]

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.

[Joe Barnett (thejoe)]

looks like https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5070 addresses this in gtk3 apps, can it (and/or the next gtk release) be added to the ubuntu package and the snap package that contains gtk3 (gnome-* snap?)

[Daniel van Vugt (vanvugt)]

I'm not totally sure that's a fix, but let's assume it is.