Obscure Window Manager Problem [Enhancement]

Bug #1918375 reported by C. Jeffery Small
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xfwm4 (Ubuntu)
New
Undecided
Unassigned

Bug Description

Xubuntu 20.04
xfwm4 4.14.1-0ubuntu1

This is a problem that only occurs under very specific conditions. However, I think it is problematic enough to deserve consideration for an enhancement.

My setup includes multiple (8) virtual desktops. I use Meta-{L,R}ArrowKey to move between desktops and Shift-Meta-{L,R}ArrowKey to move a specific window across and to different desktops.

My Window Manager settings include:
  - Focus Follows Mouse
  - Automatically give focus to newly created windows
  - Raise window when clicking inside application window

I do not use Auto raise when window receives focus.

The Problem: I move my mouse over a window on the current screen. It receives focus, but I do not click on it. I want to move the window three desktops to the left. I use Shift-Meta-LeftArrow to begin moving the window. I press it three times and discover that I have a mess! All sorts of things are on the wrong screens. I finally figured out that the original window is not "raised" because I didn't click on it. Therefore, as it moved to the first desktop to the left, it got placed beneath another window there and was completely hidden. The "higher" window then gets picked up and is moved a screen to the left. It's possible that the same thing happens (some of my windows are maximized and fill the entire screen) and the second window gets dropped and the third window now goes for a ride. If you are not paying very close attention, this is all extremely confusing.

As I said, this happens because of my particular settings. I don't like auto raise on focus because it causes a lot of visual jumping on the screen when you move the mouse around. I did try it out with a long delay, but the problem described above can still occur.

I would suggest a reasonably simple fix which is whenever a window is being moved, immediately raise it so that it floats above the other windows and never gets lost under another window. I assume that raising a window makes it "higher" then all windows on every desktop, not just the current one. Thoughts?

Tags: focus raise xfwm4
Revision history for this message
C. Jeffery Small (loyhz2ay-jeff-h670zbts) wrote :

Not getting much attention here! :-)

Here is some additional information that might be useful. I was having problems with new windows being created and hidden underneath existing windows. In a forum discussion it was suggested to turn off (uncheck) the "Activate focus stealing prevention" on the "Window Manager Tweaks->Focus" tab. This indeed was the problem and once unchecked, new windows were consistently created on the top of the stack. However, this does not address the problem of moving a window that is lower or at the bottom of the window stack to another workspace using keyboard shortcuts. The moving window may still disappear beneath other windows higher in the stack.

I have "Raise window when clicking inside application window" set so any attempt to drag a window with the mouse forces it to the top of the stack. My suggestion is that if the user has this option set, that it then also imply that any window movement initiated by a keyboard shortcut also causes the window to be raised so that it will float above all other windows as the virtual desktops (workspaces) change. Unchecking this option would leave the keyboard shortcut action as is.

Of course, it would be clearer for everyone involved if this raise-on-window-movement option was given it's own option in the Window Manager or the Window Manager Tweaks menu.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.