Launchpad has imported 20 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=1349225.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2016-06-23T02:28:42+00:00 adam 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/0 ------------------------------------------------------------------------ On 2016-06-23T07:17:39+00:00 ofourdan 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/1 ------------------------------------------------------------------------ On 2016-06-23T07:24:01+00:00 ofourdan wrote: Humm, indeed, if you turn off "raise-on-click", the client cannot raise itself but that seems pretty much to be expected. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/2 ------------------------------------------------------------------------ On 2016-06-23T08:07:28+00:00 ofourdan 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/3 ------------------------------------------------------------------------ On 2016-06-23T12:17:53+00:00 adam wrote: Thanks for the investigation! I will follow the upstream bug. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/4 ------------------------------------------------------------------------ On 2016-07-04T15:50:44+00:00 adam 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/5 ------------------------------------------------------------------------ On 2016-07-05T12:04:24+00:00 ofourdan 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/6 ------------------------------------------------------------------------ On 2016-07-05T15:41:08+00:00 adam wrote: This is an issue even when not using no click-to-raise. action-middle- click-titlebar is also broken. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/7 ------------------------------------------------------------------------ On 2016-11-25T04:51:22+00:00 rhbz 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?) Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/8 ------------------------------------------------------------------------ On 2016-11-28T20:18:57+00:00 jgotts 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! Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/9 ------------------------------------------------------------------------ On 2016-11-28T20:36:16+00:00 adam 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/10 ------------------------------------------------------------------------ On 2016-11-29T02:35:36+00:00 jgotts 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/11 ------------------------------------------------------------------------ On 2016-11-29T02:37:42+00:00 jgotts 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/12 ------------------------------------------------------------------------ On 2016-11-29T03:32:05+00:00 adam wrote: Yes, please file separate bugs for these Azureus issues. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/13 ------------------------------------------------------------------------ On 2016-12-19T13:13:31+00:00 lars 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... Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/14 ------------------------------------------------------------------------ On 2016-12-19T20:50:21+00:00 adam wrote: You can follow along on the gnome bug: https://bugzilla.gnome.org/show_bug.cgi?id=767967 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/15 ------------------------------------------------------------------------ On 2017-11-16T18:57:36+00:00 bcotton 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/25 ------------------------------------------------------------------------ On 2018-02-20T15:24:23+00:00 bcotton wrote: This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/26 ------------------------------------------------------------------------ On 2019-05-02T22:07:09+00:00 bcotton 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/36 ------------------------------------------------------------------------ On 2020-04-28T09:20:49+00:00 mildred-bug.redhat 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1698083/comments/37 ** Changed in: gnome-shell (Fedora) Status: Unknown => Confirmed ** Changed in: gnome-shell (Fedora) Importance: Unknown => Undecided ** Bug watch added: bugzilla.gnome.org/ #445447 https://bugzilla.gnome.org/show_bug.cgi?id=445447 ** Bug watch added: bugzilla.gnome.org/ #767967 https://bugzilla.gnome.org/show_bug.cgi?id=767967 ** Bug watch added: gitlab.gnome.org/GNOME/mutter/issues #602 https://gitlab.gnome.org/GNOME/mutter/issues/602 ** Bug watch added: gitlab.gnome.org/GNOME/gtk/issues #1895 https://gitlab.gnome.org/GNOME/gtk/issues/1895 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1698083 Title: Middle-click titlebar actions (like maximizing vertically) don't work (for all apps in Wayland sessions, and CSD apps in Xorg sessions) Status in GTK+: New Status in Mutter: Unknown Status in gnome-shell package in Ubuntu: Confirmed Status in gtk+3.0 package in Ubuntu: Confirmed Status in mutter package in Ubuntu: Confirmed Status in gnome-shell package in Fedora: Confirmed 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) To manage notifications about this bug go to: https://bugs.launchpad.net/gtk/+bug/1698083/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
