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

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.

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.

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

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.

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

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.

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

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

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

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!

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

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.

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.

Yes, please file separate bugs for these Azureus issues.

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

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

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.

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

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.

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