Bug 1349225 - Client-side decorated windows cannot raise or lower themselves on wayland (as in action-middle-click-titlebar=lower)
Summary: Client-side decorated windows cannot raise or lower themselves on wayland (as...
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks: WaylandRelated
TreeView+ depends on / blocked
 
Reported: 2016-06-23 02:28 UTC by Adam Goode
Modified: 2019-06-05 13:54 UTC (History)
8 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 767967 None None None 2019-05-03 03:15 UTC

Description Adam Goode 2016-06-23 02:28:42 UTC
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.

Comment 1 Olivier Fourdan 2016-06-23 07:17:39 UTC
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.

Comment 2 Olivier Fourdan 2016-06-23 07:24:01 UTC
Humm, indeed, if you turn off "raise-on-click", the client cannot raise itself but that seems pretty much to be expected.

Comment 3 Olivier Fourdan 2016-06-23 08:07:28 UTC
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.

Comment 4 Adam Goode 2016-06-23 12:17:53 UTC
Thanks for the investigation! I will follow the upstream bug.

Comment 5 Adam Goode 2016-07-04 15:50:44 UTC
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.

Comment 6 Olivier Fourdan 2016-07-05 12:04:24 UTC
(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.

Comment 7 Adam Goode 2016-07-05 15:41:08 UTC
This is an issue even when not using no click-to-raise. action-middle-click-titlebar is also broken.

Comment 8 Peter Simonyi 2016-11-25 04:51:22 UTC
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?)

Comment 9 John Gotts 2016-11-28 20:18:57 UTC
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!

Comment 10 Adam Goode 2016-11-28 20:36:16 UTC
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

Comment 11 John Gotts 2016-11-29 02:35:36 UTC
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.

Comment 12 John Gotts 2016-11-29 02:37:42 UTC
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.

Comment 13 Adam Goode 2016-11-29 03:32:05 UTC
Yes, please file separate bugs for these Azureus issues.

Comment 14 Lars E. Pettersson 2016-12-19 13:13:31 UTC
(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...

Comment 15 Adam Goode 2016-12-19 20:50:21 UTC
You can follow along on the gnome bug:
https://bugzilla.gnome.org/show_bug.cgi?id=767967

Comment 16 Fedora End Of Life 2017-11-16 18:57:36 UTC
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.

Comment 17 Fedora End Of Life 2018-02-20 15:24:23 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 18 Ben Cotton 2019-05-02 22:07:09 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.