mate/marco window focus selection behavior should resemble a stack

[garberw]

Expected behaviour

when closing a window A, focus should return (pop off stack) to window that had the focus just before window A got the focus.
in other words, there should be a stack of windows successively having the focus.
this is what normally happens in other operating systems or window managers (compiz works as expected).

Actual behaviour

when window A is closed behavior is unpredictable. Often focus returns to desktop. Behavior varies with programs and
associated windows having the focus.

Steps to reproduce the behaviour

open window B, open window A, close window A, see whether window B still regains focus.

MATE general version

garberw@electron> rpm -qa | grep marco
marco-1.24.1-1.fc32.x86_64
marco-libs-1.24.1-1.fc32.x86_64
garberw@electron>

Package versionmate-desktop-1.24.1-1.fc32.x86_64

Linux Distribution

fedora 32

Link to downstream report of your Distribution

[garberw]

https://nest.parrot.sh/packages/debian/marco/blob/debian/1.22.3-1/doc/how-to-get-focus-right.txt

this commented source code explains why I am getting this problem, so this bug report is more like a feature request.
in other words, they should return to the way gnome 2 originally worked regarding window focus.

[jan-kiszka]

I see this issue with marco-1.24.1-lp152.1.1.x86_64 / libmarco-private2-1.24.1-lp152.1.1.x86_64 on OpenSUSE 15.2 as well.

I'm not sure if that is the same problem, but I can also see new windows with focus not getting into the foreground. Reproduce with Okular e.g.: open another file from an existing instance, and the focus returns to the first window, rather than the newly opened one.

All that looks to me like regressions compared to 1.20.1 where I was before (OpenSUSE 15.1) and such problems did not occur.

[garberw]

https://github.com/jothan/mate-window-manager/blob/master/doc/how-to-get-focus-right.txt

this web page explains that this is an (unpopular) "feature" and not a bug.
in gnome2 when you are
(1) in a window and you
(2) launch a second windowed program,

after the second windowed program exits you expect

(3) the focus to return to the first window.

Instead this update on the github website above seems to make
focus mainly dependent on where the pointer (mouse) is.
It is therefore not a bug, but makes it awkward since the
desktop is usually under the pointer, so you have to press
"alt - tab" to switch to the previous window.
Since pressing "alt-tab" over and over and over and over
is already a big nuisance for something like programming or
data entry, this mouse focus choice is not going to be a popular "feature"
because now you have to press "alt-tab" twice as often,
However, for some users mouse focus could be a useful "optional feature".
Wiping out the traditional standard gnome2 behaviour is frustrating me.

So what is "mouse focus" intended to help? Gamers?
those kind of users probably would not use mate desktop anyway.

I have found entire blog postings (sorry no link now) with users
who are confused by this new default setting. That is why I think
this mouse focus default choice is unpopular.

the problem is in the marco window manager (under mate desktop).
when switching to compiz window manager I get the
desired standard traditional focus behavior,
but then there are other distracting problems with compiz
which is why I (used to) like marco.

Yes I can see that a lot of thought went into the current design;
sorry I do not like it. Begging you to bring back the old method
and make it an option instead of removing it.

[garberw]

https://bugs.launchpad.net/linuxmint/+bug/1359199
https://ubuntu-mate.community/t/cant-seem-to-disable-focus-follows-mouse/9780/2
#251
looks like behavior of "focus follows mouse" was under development and
it is hard to make everyone happy; some like it and some do not; so why
not make it an option; it was originally and option;

[garberw]

#251

[jan-kiszka]

If this is a feature, I'm fine with it when it can be controlled somewhere. For me, an essential feature of mate is its conservatism its behavior, or the option to configure that.

I'm currently back to 1.20.1 because it became impossible for me to work normally: Some open windows didn't appear in the foreground, rather the one that opened it. Too often, the focus went to the desktop after closing others (and my mouse cursor was almost always over the previously focused windows because most of my windows are maximized and my panel is small).

[MikePooh]

I have the similar problem with Marco 1.24.1 on Arch Linux. I am using Double Commander File manager (Qt based version). There is built-in function that allows to view the text file right inside the file manager. After escape the text file viewer focus doesn't back to DC main. So you have to press alt+tab to back to the file manager. This is very annoying. This behavior doesn't observe on my Linux Mint Mate with Marco 1.24.0.

[graywolf2]

This problem was reported also here:
https://bugzilla.redhat.com/show_bug.cgi?id=1873747

[wereii]

I am either unable to reproduce this properly, or well, it works exactly how you describe in Manjaro.

$ marco --version
1.24.1
$ yay -Qi marco 
Version         : 1.24.1-1
$ uname -A
5.9.10-1-MANJARO

If I open terminal A, B and C, then tab/focus them in this order BCA, then closing A focuses C, closing C focuses B.

[jan-kiszka]

Try KDE programs as well. I was seeing issues with konsole and okular e.g.

[graywolf2]

The same issue exists in Fedora 33.

[ralesk]

Do you guys ever get a situation where no window appears to be focused (after closing some window), but keyboard events definitely go into it? I wonder if it's related.

We use Slack at work, and Slack calls have these weird extra windows without frames and what not (which might or might not contribute to the confusion in Marco) — and I think after those close is when the window manager gets a bit disoriented, but I couldn't quite reproduce it yet. I use Konsole as terminal, and that's how I noticed that if a Konsole was on top when the "no window is focused" thing is going on, Konsole would display the empty cursor, as if unfocused (I guess it guesses from whether the window manager tells it that its window is focused), but if I type into it, it'll happily display characters.

So yeah, not sure if it's related, but feels like it might be, in the general scope of handling window stacks properly.

[garberw]

Expected behaviour

$ gsettings set org.mate.Marco.general focus-mode click
log out
log in
when
run app1
run app2
exit app2
focus returns to previously focused app1 

Actual behaviour

focus returns to app underneath mouse

Steps to reproduce the behaviour

MATE general version

Package version

garberw@electron> rpm -qa | grep mate-desktop
mate-desktop-libs-1.24.1-3.fc33.x86_64
mate-desktop-1.24.1-3.fc33.x86_64

Linux Distribution

fedora 33

Link to bugreport of your Distribution (requirement)

https://bugzilla.redhat.com/show_bug.cgi?id=1859417

[ZaxonXP]

I see on this project main page the following:

Change focus mode:

gsettings set org.mate.Marco.general focus-mode mouse
gsettings set org.mate.Marco.general focus-mode sloppy
gsettings set org.mate.Marco.general focus-mode click

Could you please add one more option: gsettings set org.mate.Marco.general focus-mode stack ?
That way everybody would be happy to choose what they like. :)

Kind regards,
Zaxon

[simonbelmont]

Upgraded to Debian 11 and this behaviour stops the auto-type feature of KeepassXC from working, amongst many other things, if your workflow involves hotkeys or a lot of keyboard. An option for old school behaviour would be very nice.

[jenav]

Wait, what? i was searching for the bug but this is a feature?

It's annoying, impractical, and it's not the behaviour it had for, how many years? and no option to change it back either. jesus

[FreaxMATE]

For me it only happens for qt apps. When I close a qt app the window focused before is not focused automatically. Does it only affect qt (or non-gtk) apps for you as well?

[andreymal]

It's also easily reproducible with two xterm windows

gtk windows seem to work fine

[jenav]

Yes, seems to happen with whatever is not gtk based: qt apps, chromium 🤔, mpv, xterm, st, feh, mupdf, etc, etc, etc.

So, gtk apps are in the circle of trust and marco is jack byrnes

[MikePooh]

After update Linux Mint from 20.2 Uma to 20.3 Una with Macro 1.26.0 the problem starts observing.

[edisno]

Is it really not possible to switch back to the old "proper" behaviour? To me the current behaviour feels very broken.

[pokotilenko]

1. Firefox started by a global hotkey does not get focus. It only gets focus if active window was Firefox.
2. Open Caja, open image from it (Eye Of Mate), close image window (Esc/Alt-F4/Ctrl-W), sometimes Caja gets focus back, mostly it doesn't. This behaviour does not depend on pointer position. If there are other windows under the Caja in the stack - non of them get focus, not even Desktop.

This is quite strange feature as most of Mate users are using Mate to have old, established behaviour.

[pokotilenko]

https://github.com/jothan/mate-window-manager/blob/master/doc/how-to-get-focus-right.txt

this web page explains that this is an (unpopular) "feature" and not a bug. in gnome2 when you are (1) in a window and you (2) launch a second windowed program,

after the second windowed program exits you expect

(3) the focus to return to the first window.

Instead this update on the github website above seems to make focus mainly dependent on where the pointer (mouse) is. It is therefore not a bug, but makes it awkward since the desktop is usually under the pointer, so you have to press "alt - tab" to switch to the previous window.

Looking at descrition in a link I don't see explaination of this strange behaviour for a "click" focus method which I use.
Actually for a "when a focused window is closed or minimized" case it states that in "click" focus method action is: "Focus the most recently used window (same as the window on top)" which is not what happening for me.

So, it seem to be a bug.

BTW, I use Debian 11 with stock Mate 1.24.1 and Marco as WM.

[dark-penguin]

https://github.com/jothan/mate-window-manager/blob/master/doc/how-to-get-focus-right.txt

Actually, I don't see anything about this being a feature. This clearly says:

However, there are a number of cases where the current focus window
becomes invalid and another should be chosen.  Some examples are when
a focused window is closed or minimized, or when the user changes
workspaces.  In these cases, there needs to be a rule consistent with
the above about the new window to choose.

Focus method  Behavior
    click     Focus the most recently used window (same as the window
              on top)

I'm using the "click" focus method, like I'm sure ~99,99% other users do because it allows easy keynav with no contradictions, so the rest does not matter.

I'm encountering this problem when opening a video file in SMPlayer, and then closing it - either by pressing Esc, or Alt+F4, or clicking the "X" icon. Then I want to return to the Caja window, to press "Delete" to remove this video, then "Down" for the next video, and "Enter" to open it. What actually happens is: after closing SMPlayer, keyboard focus is randomly either on the panel, or on the desktop, or nowhere to be seen. There is absolutely no logical explanation for focus switching randomly to the panel after closing a window that had nothing to do with the panel. So this is definitely a bug, and NOT a "feature". It basically contradicts the documentation. (Unless we're talking about different things and I'm completely missing the point.)

EDIT: Tried it with Eye of Mate - it's a part of MATE and not a Qt app, so you can't blame it on Qt.

• Test: open an image from a Caja window (with a mouse or with Enter), close it, see if Caja is back in focus.
• Actual result: sometimes it is, and sometimes it is not, RANDOMLY!! Open one image, close it (Esc or Alt+F4), the focus is back in Caja. Open the same image again, close it - focus is NOT back in Caja.

Seriously, is THIS a feature, or are we missing something?!

(This is on Debian 11, marco 1.24.1-3)

[ZaxonXP]

I think by making this "feature" I had enough reasons to move to the tiling window manager. :)

[palacsint]

I have the same issue after Debian 10 -> 11 upgrade and on another machine after Ubuntu 18.04 -> 22.04 upgrade.
Mate version: 1.24.1 (Debian), 1.26 (Ubuntu)

Start a mate-terminal
Start another mate-terminal from the previous mate-terminal
exit
Window focus is on the first mate-terminal (that's good)

Start a mate-terminal
Start "feh myimage.png" from the mate-terminal
Close feh
Window focus is nowhere

Start xterm
Start another xterm from the previous xterm
exit
Window focus is nowhere

That's really annoying, breaks the flow and is not consistent at all.

[ftoledo]

still no workaround? backport??

[mmhere]

So, how hard is it to, say, install 1.20.1 on a newish sytem running Linux Mint 21 or Ubuntu 22.04? 1.26.0 is definitely broken. 1.20.1 on an older Ubuntu machine I have does not suffer the problems created by this buggy/inconsistent behaviour.

Naturally (on Linux Mint 21), this doesn't work because the packages don't include old versions:

apt-get -s install marco=1.20.1-2ubuntu1 # -s => preflight first

nor this:

apt-get -s install marco=1.20.1 # -s => preflight first

So do I build it myself? Yuck.

I've used MATE (and Marco) for years due to its lightweight classic behaviour, but breaking basic window focus policy and not offering an option for those who want the working logic is... well, insert anti-praise here.

This has forced me to compiz, which is... OK, but this in turn breaks x11vnc access from remote vncviewer programs. So I temporarily switch to marco when doing vnc, suffer the window weirdness, then switch back to compiz after I exit vnc sessions.

Not ideal.

[mmhere]

Come to think of it,metacity (version 3.44.0 on a just-upgraded Linux Mint 21 box) may be a good replacement for marco 1.26.x at this point.

Metacity is pretty close to Marco for how they both appear and function (when functioning properly), plus the x11vnc<-->vncviewer problems are not present like when metacity is in use. I lose the compiz eye candy (which I was kinda starting to like :-), but that's a small sacrifice to have a functional window manager.

Tentatively, then, buh-bye marco. Nice to knew ya.

(metacity --replace >& /dev/null &)

P.S.: dconf-editor org.gnome.desktop.wm.keybindings to get all that stuff to match.

[mmhere]

So, how hard is it to, say, install 1.20.1 on a newish sytem running Linux Mint 21 or Ubuntu 22.04? 1.26.0 is definitely broken. 1.20.1 on an older Ubuntu machine I have does not suffer the problems created by this buggy/inconsistent behaviour.

I'll answer my own question; this is on Linux Mint 21, which is Ubuntu based, so pulling Ubuntu packages often works. Found the Ubuntu archive site for Marco 1.20.1 and the relevant package. To wit:

$ wget --quiet --output-document=marco_1.20.1-2ubuntu1_amd64.deb 'http://archive.ubuntu.com/ubuntu/pool/universe/m/marco/marco_1.20.1-2ubuntu1_amd64.deb'

$ file marco_1.20.1-2ubuntu1_amd64.deb
marco_1.20.1-2ubuntu1_amd64.deb: Debian binary package (format 2.0), with control.tar.xz, data compression xz

$ dpkg --info marco_1.20.1-2ubuntu1_amd64.deb | grep Version
 Version: 1.20.1-2ubuntu1

$ sudo dpkg --install marco_1.20.1-2ubuntu1_amd64.deb
  # (dpkg output elided)

$ marco --version
marco 1.20.1

$ ( marco --replace >& /dev/null &)

Bob's your uncle.

[tm2209]

I will just use mate-terminal to give a test example to keep it simple with default "click" mode set.

1. Launch two mate-terminal windows
2. In window 2, type "mate-terminal" but do not press return just yet
3. Move the mouse pointer to hover over window 1
4. Press return and window 3 opens and it gains focus (as noticed by the color in the window title bar)
5. Type into window 3 "exit". The window closes.
6. PROBLEM: window 2 does not gain focus (based on window title bar color).
7. PROBLEM: No window has focus (based on window title bar color). I assume this state is like what happens to "mouse" mode and we have "no_focus_window" instead of what "click" mode is supposed to do (prior window):
   mouse Focus the non-DESKTOP window containing the pointer if
   there is one, otherwise focus the designated
   "no_focus_window".
8. PROBLEM: Type any keys and they echo in window 1. So it has gained keyboard focus but not full window focus indicated by window title bar color.
9. While in this "no_focus_window" state where no window title bar color indicates a focused window, use the keyboard to switch to another desktop and then switch back. This causes window 2 to gain full focus (window title bar color). You can do it as previously mentioned with Alt-Tab too.

The "click" mode says on window close:
click Focus the most recently used window (same as the window
on top)

Is does not do that now. This IS a bug, not a feature. The fact that you can have keyboard focus and window (title bar color) focus in different states is a problem.

I installed marco-1.20.1 per a previous comment and dpkg failed. But it was enough to install /bin/marco. I made a copy of it and reinstalled the current marco version to fix broken packages. Now I can do /usr/local/bin/marco-1.20.1 --replace >& /dev/null &) to switch to the old version easily until this bug is fixed. Or... I can rename it to marco and it will be used by default because /usr/local/bin is in PATH ahead of /bin (seamless, no pain workaround).

I hit this bug all the time. I create windows and when they close, I continue typing without re-clicking the prior window. To have those keystrokes randomly go to other windows, the windows that just happen to be under the mouse pointer at the time is TOTALLY RIDICULOUS!!!

I hope my observation that the bad state is when no window has focus, i.e. "no_focus_window" is in play, will point to an area in the code to fix.

[mmhere]

yah, my dpkg instructions were incomplete. apologies. I did something similar and ended up with the 1.20.1 /usr/bin/marco binary (of which I kept a copy) installed amidst the rest of the current 1.26.* package stuff. A hack, but it functions.

[balazs-endresz]

Reverting f96255beb fixed the focus issue for me:

git revert f96255beb
git checkout --theirs src/core/workspace.h
git add src/core/workspace.h
git revert --continue

It needed the following dependencies to install locally on a fresh ubuntu mate 22.04 vm:

sudo apt install gettext meson mate-common yelp-tools make autoconf autopoint libglib2.0-dev libgtk-3-dev libcanberra-gtk-module libcanberra-gtk3-module libcanberra-gtk3-dev libxpresent-dev x11proto-present-dev
./autogen.sh --prefix /usr && make
( ./src/marco --replace >& /dev/null &)

[codeparity]

So, how hard is it to, say, install 1.20.1 on a newish sytem running Linux Mint 21 or Ubuntu 22.04? 1.26.0 is definitely broken. 1.20.1 on an older Ubuntu machine I have does not suffer the problems created by this buggy/inconsistent behaviour.

I'll answer my own question; this is on Linux Mint 21, which is Ubuntu based, so pulling Ubuntu packages often works. Found the Ubuntu archive site for Marco 1.20.1 and the relevant package. To wit:

$ wget --quiet --output-document=marco_1.20.1-2ubuntu1_amd64.deb 'http://archive.ubuntu.com/ubuntu/pool/universe/m/marco/marco_1.20.1-2ubuntu1_amd64.deb'

$ file marco_1.20.1-2ubuntu1_amd64.deb
marco_1.20.1-2ubuntu1_amd64.deb: Debian binary package (format 2.0), with control.tar.xz, data compression xz

$ dpkg --info marco_1.20.1-2ubuntu1_amd64.deb | grep Version
 Version: 1.20.1-2ubuntu1

$ sudo dpkg --install marco_1.20.1-2ubuntu1_amd64.deb
  # (dpkg output elided)

$ marco --version
marco 1.20.1

$ ( marco --replace >& /dev/null &)

Bob's your uncle.

Thanks
this annoyance still exists on debian
lsb_release -d
Description: Debian GNU/Linux 11 (bullseye)

downgrading to ubuntu release package seems to break the system, a workaround that seems to work so far is to extract the marco binary from the package mentioned, and put it in some cutsom path ($HOME/bin/) etc
created a startup entry under System>Perfrences>Personal>Starup Applications
Under Startup Programs click "Add"
Fill in anything to your fancy, mine looks like this

tx

[balazs-endresz]

@codeparity The focus issue should be significantly improved since 1.26.1, so you could try that instead. Occasionally it still happens for me though, only maybe one out of a few hundred times.

[github-userx]

https://github.com/jothan/mate-window-manager/blob/master/doc/how-to-get-focus-right.txt

Actually, I don't see anything about this being a feature. This clearly says:

However, there are a number of cases where the current focus window
becomes invalid and another should be chosen.  Some examples are when
a focused window is closed or minimized, or when the user changes
workspaces.  In these cases, there needs to be a rule consistent with
the above about the new window to choose.

Focus method  Behavior
    click     Focus the most recently used window (same as the window
              on top)

I'm using the "click" focus method, like I'm sure ~99,99% other users do because it allows easy keynav with no contradictions, so the rest does not matter.

I'm encountering this problem when opening a video file in SMPlayer, and then closing it - either by pressing Esc, or Alt+F4, or clicking the "X" icon. Then I want to return to the Caja window, to press "Delete" to remove this video, then "Down" for the next video, and "Enter" to open it. What actually happens is: after closing SMPlayer, keyboard focus is randomly either on the panel, or on the desktop, or nowhere to be seen. There is absolutely no logical explanation for focus switching randomly to the panel after closing a window that had nothing to do with the panel. So this is definitely a bug, and NOT a "feature". It basically contradicts the documentation. (Unless we're talking about different things and I'm completely missing the point.)

EDIT: Tried it with Eye of Mate - it's a part of MATE and not a Qt app, so you can't blame it on Qt.

• Test: open an image from a Caja window (with a mouse or with Enter), close it, see if Caja is back in focus.
• Actual result: sometimes it is, and sometimes it is not, RANDOMLY!! Open one image, close it (Esc or Alt+F4), the focus is back in Caja. Open the same image again, close it - focus is NOT back in Caja.

Seriously, is THIS a feature, or are we missing something?!

(This is on Debian 11, marco 1.24.1-3)

Im just a very regular Ubuntu user (so I’m obviously only understanding half of what people are writing in this thread.

But yeah, exactly what you’re describing drove me crazy on Ubuntu-Mate 22.04 (compared to my 20.04 machines): I open a video file with mpv then close it with pressing „q“ and want to delete the file with „Del“ but my focus isn’t in the window of the folder anymore and I have to click into it first.

Now I do wonder if this will be fixed in 24.04. I fell in love with Ubuntu-Mate for it’s „just works“ vibe. I don’t want to spend too much time on configuring things (I already struggle big time with the fact that on Linux I’ll have to look more into hdparm to stop my external WD hard drives from spinning for hours or spinning up/down every hour even when not in use). But I’m not giving up…Linux Desktop experience has come a long way since 2014 when I switched from WindowsXP).

[balazs-endresz]

@github-userx This should be (mostly) fixed in 1.26.1 but 22.04 still seems to ship only 1.26.0: https://manpages.ubuntu.com/manpages/jammy/man1/marco.1.html
I'm not sure what's a safe/simple way to upgrade it manually now. At least Ubuntu 23.10 has marco 1.26.2 already, so I guess the next LTS in April will have this fix too.

[andreymal]

Hm, I use marco 1.26.2 in Arch Linux but still have this issue Guake/guake#1816

[github-userx]

Message ID: ***@***.***>This is great to know, many thanks! I’m exited for 24.04