After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 705200 - raise-or-lower works eratically
raise-or-lower works eratically
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
3.15.x
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2013-07-31 10:59 UTC by Christophe Rhodes
Modified: 2017-02-07 13:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix erratic raise_or_lower behavior patch (2 bytes, patch)
2017-02-06 16:21 UTC, Jose Marino
none Details | Review
Fix erratic raise_or_lower behavior patch (800 bytes, patch)
2017-02-06 17:20 UTC, Jose Marino
none Details | Review
keybindings: fix erratic raise_or_lower behavior (1.17 KB, patch)
2017-02-07 13:40 UTC, Rui Matos
committed Details | Review

Description Christophe Rhodes 2013-07-31 10:59:45 UTC
The "Raise window if covered, otherwise lower it" functionality works some of the time.  Other times, when windows are apparently at the top of the window stack on the desktop, pressing the raise_or_lower keybinding does nothing (i.e. leaves the active window on top).

There's some diagnosis of this issue in the Red Hat bugzilla at https://bugzilla.redhat.com/show_bug.cgi?id=827099 -- I haven't investigated to see whether the diagnosis is accurate, but the symptoms described are the same (and I couldn't find that report as having been sent upstream to here).
Comment 1 Kent Rogers 2014-11-14 15:39:57 UTC
The diagnosis in https://bugzilla.redhat.com/show_bug.cgi?id=827099 appears
accurate to me.  The presence of a window in a "secondary" workspace
definitely appears to trigger the issue.

This is still a problem for me on Fedora 20 and my version of gnome-shell is:

$ rpm -q gnome-shell
gnome-shell-3.10.4-9.fc20.x86_64
Comment 2 Jose Marino 2017-02-03 17:47:22 UTC
I've been running into this issue repeatedly (on cinnamon/muffin) and it is very annoying. 
I decided to dig into the code and I have discovered the cause. Function "handle_raise_or_lower (src/core/keybindings.c)" is called when running 'raise-or-lower' on a window. This function iterates through all the windows in the stack to determine if our window is already on top or obscured. The problem is that the window stack includes windows in another workspaces and also windows that are minimized.

I have identified 2 distinct erratic behaviors:
- 1st one is the one described originally in this bug report: our window is already on top. We run 'raise-or-lower' on it, repeatedly, and nothing happens.
This is caused by the code finding another window in a different workspace that is on top of our window, causing the code to raise our window. Since our window was already on top in our workspace, nothing happens.
- 2nd behavior: our window is on top, we run 'raise-or-lower' and nothing happens. However, we run it again and now the window is lowered.
This happens because a minimized window is identified as being on top. The first 'raise-or-lower' raises our window, but it was already on top so nothing happens. The second 'raise-or-lower' actually lowers it.

Both behaviors are fixed by the following patch:

diff --git a/src/core/keybindings.c b/src/core/keybindings.c
index b7853e2..48aab75 100644
--- a/src/core/keybindings.c
+++ b/src/core/keybindings.c
@@ -3198,7 +3198,7 @@ handle_raise_or_lower (MetaDisplay     *display,
     {
       MetaRectangle tmp, win_rect, above_rect;
 
-      if (above->mapped)
+      if (above->mapped && meta_window_should_be_showing(above))
         {
           meta_window_get_frame_rect (window, &win_rect);
           meta_window_get_frame_rect (above, &above_rect);
Comment 3 Rui Matos 2017-02-06 13:39:30 UTC
Thanks for looking into this, can you provide a git formatted patch?

(In reply to Jose Marino from comment #2)
> diff --git a/src/core/keybindings.c b/src/core/keybindings.c
> index b7853e2..48aab75 100644
> --- a/src/core/keybindings.c
> +++ b/src/core/keybindings.c
> @@ -3198,7 +3198,7 @@ handle_raise_or_lower (MetaDisplay     *display,
>      {
>        MetaRectangle tmp, win_rect, above_rect;
>  
> -      if (above->mapped)
> +      if (above->mapped && meta_window_should_be_showing(above))

please leave a space to follow mutter's style: _showing (above)

Otherwise this looks good to me.
Comment 4 Jose Marino 2017-02-06 16:21:43 UTC
Created attachment 345040 [details] [review]
Fix erratic raise_or_lower behavior patch

Patch on top of git master from today (57f80f091f2e0). Created with "git format-patch".
Comment 5 Jose Marino 2017-02-06 17:20:21 UTC
Created attachment 345043 [details] [review]
Fix erratic raise_or_lower behavior patch

Something went wrong with my first patch, here it goes again:
Patch on top of git master from today (57f80f091f2e0). Created with "git format-patch".
Comment 6 Rui Matos 2017-02-07 13:40:15 UTC
Created attachment 345116 [details] [review]
keybindings: fix erratic raise_or_lower behavior

Function "handle_raise_or_lower (src/core/keybindings.c)" is called
when running 'raise-or-lower' on a window. This function iterates
through all the windows in the stack to determine if our window is
already on top or obscured. The problem is that the window stack
includes windows in another workspaces and also windows that are
minimized.
Comment 7 Rui Matos 2017-02-07 13:42:05 UTC
Review of attachment 345116 [details] [review]:

I just added your explanation from comment #2 to commit message. Code looks good, thanks
Comment 8 Rui Matos 2017-02-07 13:45:56 UTC
Attachment 345116 [details] pushed as 58669e7 - keybindings: fix erratic raise_or_lower behavior