strange window switching foreground/background behavior [$50 awarded]

[jmssil]

I've been experiencing difficulties with marco on Linux Mint 17.3. These problems did not happen after a recent fresh install, but soon afterwards.

It's hard to explain, but basically when I click to switch windows in the task bar (window list) the selected windows is not brought to the front, it stays in the back. So, it looks like I'm clicking on the correct window, but I'm clicking in one in the background.

It looks like the foreground/background + window switching logic is wrong.

Associated with this, there is a strange shadow between the maximized windows and the task bar. I'm attaching a screenshot.

---

The $50 bounty on this issue has been claimed at Bountysource.

[jmssil]

I found this happens only after running HexChat in a session, even if I close it afterwards.

[evaldas325]

Hi, this is biggest annoyance for me since upgrade to 1.12. I reproduce this bug constantly on Debian/testing desktop with dual monitor setup. Also I installed Linux Mint 17.3 on laptop and started to reproduce this problem as well. I do not use HexChat. I have 4 workspaces with lots of windows open. Have no idea what program/window causes this but this affects all windows opened on current workspace.

[flexiondotorg]

I have experienced this on Ubuntu MATE 15.10 with MATE 1.12 installed. But, I'm using Compiz, so I don't think Marco is to blame.

[evaldas325]

Restarting Marco helps me. If I run into this weird window behavior, I execute " marco --replace" in terminal and the problem is gone.

[evaldas325]

In my previous message I said that executing "marco --replace" fixes the problem temporary until windows start switching to foreground/background again unpredictably.
However I've tried "marco --replace --no-composite" and it seems turning off compositioning solves the problem permanently.

[jmssil]

However I've tried "marco --replace --no-composite" and it seems turning off compositioning solves the problem permanently.

I seem to confirm this.

[jlacroix82]

I can also confirm this bug on Ubuntu MATE 16.04 with Marco. If it helps, the machine I encounter this on has a Haswell i7 CPU, 16GB RAM, Geforce GTX 760 video card. I have two other machines, both with Intel graphics, and I've never seen this issue on those machines.

[pasikarkkainen]

I'm seeing this same bug on Fedora 24. It seems to happen often (but not always) after switching workspace from the MATE workspace switcher applet.

So basicly after changing the active workspace some random window is on the foreground, but focus is actually on some background window.. so you think you're using/clicking the foreground window, but in reality all the actions go to the background window. The way to fix this is to minimize all windows from the workspace and then maximize/open the window you need. It's super annoying.

I didn't have this bug with Fedora 22, which obviously used older version of MATE/marco.

[jlacroix82]

This bug was reported back in January. Has it been assigned to a developer yet, or are we just talking amongst ourselves?

[jmssil]

From the column on the right, nothing has been made concerning this issue. It seems strange to me, since it seems a major regression, but I don't know how development in MATE/marco works.

[daemonblade]

It also happens with mate-1.12 on FreeBSD.

[allanlaal]

happens in Ubuntu 16.04 LTS too

[jlacroix82]

What do we need to do in order to get this assigned to someone? MATE is too frustrating to use with this bug. I just tried upgrading MATE from the PPA but it's still not fixed. This happens so frequently for me that window navigation is a major nuisance. I'm going to try disabling compositing to see if that helps. If not, I may switch to GNOME, as this problem is not present there.

[raveit65]

I'm seeing this same bug on Fedora 24. It seems to happen often (but not always) after switching workspace from the MATE workspace switcher applet.

I can't confirm this with f24 and Mate-1.16 (gtk3 version) and origin nvidia driver 940xxx.

It's hard to explain, but basically when I click to switch windows in the task bar (window list) the selected windows is not brought to the front, it stays in the back.

Since fedora 18 i'm building official fedora mate packages but i never run in this issue with my main box and my laptop (intel graphics).

[pilot51]

Disabling compositing worked for me.

I am aware of two GUI methods to disable it in Mint 18:

1. Preferences -> Windows -> uncheck 'Enable software compositing window manager'
2. Preferences -> Desktop Settings -> Windows -> Window Manager -> pick 'Marco' (without + Compositing)

[raveit65]

PS: i'm using always this settings.
[rave@mother ~]$ gsettings get org.mate.Marco.general auto-raise
true
[rave@mother ~]$ gsettings get org.mate.Marco.general focus-mode
'sloppy'

Maybe this is the reason why i never run in this issue.

[raveit65]

If someone can provide steps to reproduce or a video i'm happy to use 'git bisect' to find a culprit commit which probably caused the issue since 1.10 of whatever.
Marco is independent to most other packages, so this should work if we know since what time the issue occurs.

[jlacroix82]

The problem with reproducing this bug, is that I can't seem to find a way to reproduce it at all. Sometimes it happens, sometimes it doesn't. It happens most often when I switch to another workspace.

[pasikarkkainen]

Yep, it's hard to give exact information to reproduce. It happens randomly, but quite often, ie. usually many times per hour.

My environment currently is Fedora 24 Mate + two displays .. and it happens quite often after switching workspaces.

[jmssil]

Try hexchat to see if it triggers the issue.

[raveit65]

My environment currently is Fedora 24 Mate + two displays .. and it happens quite often after switching workspaces.

I don't have a second monitor to reproduce but i will connect my monitor to my laptop for a while.
...but i'm working normal on a powerful PC and all my confs aren't on my laptop, so i can't do that really a long time.
Any chance to work with one monitor for a while to see if the issue occurs?

Try hexchat to see if it triggers the issue.

Looks like a chance to switch configs from xchat to hexchat .

[raveit65]

PS: Can you please test those settings?
#251 (comment)

[pilot51]

I have two 1920x1080 monitors, 4 workspaces that I regularly switch between, and usually about a half dozen or so windows across all workspaces with a couple set to always show on visible workspace. The windows I usually have open are Mumble, Discord, Firefox, Steam, KVIrc, and often Caja and Xed. I've never used Hexchat. The issue was especially annoying when I was doing development with about twice as many windows. I never found reproducible steps, but I think it may have been related to switching between workspaces when there are windows overlaying each other.

[jlacroix82]

The comment from pilot51 seems to mirror my setup. I have two displays and the problem happens when I switch from one workspace to another. I've seen this happen with MATE applications too, like Caja or Pluma for example. It's hard to reproduce on demand. I see this problem several times a day but window management also works as expected sometimes.

[fredo-m]

Hi,

I had the same bug, I had opened a bug report on Debian's bug tracker:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828077

I opened the bug against mate-panel, but it seems that marco is involved.

I have several applications open on my 5 workspaces including several in the same workspace. Application windows are open to the maximum, I click on the panel at the bottom of the screen to move from one application to another.

After a few hours of use, I have not found a trigger but it is necessary to be passed several times from one workspace to another, the application that is visible in a workspace is no longer clickable.
It seems that this is an application that is below that is clickable.
To find which application is clickable, I have to click one by one on all the buttons on the panel.

I do not know if it's related, but it appears the same time, the libreoffice main menu which is normally written in black is written in white.

Regards.

[jlacroix82]

This bug doesn't appear to be assigned to anyone. What do we need to do, in order to get this bug assigned to a developer? It appears that we're just talking amongst ourselves.

[raveit65]

This bug doesn't appear to be assigned to anyone. What do we need to do, in order to get this bug assigned to a developer? It appears that we're just talking amongst ourselves.

Be relaxed and google my nick name :-)

[jlacroix82]

Sorry, I didn't notice you were listed as a developer. I'm glad you're looking at this.

[jmssil]

@raveit65 I'm now using LMDE with Cinnamon, but I'm just experimenting, so I may come back to Linux Mint with MATE soon.

Anyway, is there a way to compile some component (MATE, marco, etc.) with debugging messages so we now what's happening?

A summary of conditions to reproduce:

1. try running hexchat if you find it hard to trigger the issue, in my case hexchat triggers the issue immediately (if I'm not mistaken);
2. I think that having multiple workspaces is mandatory to reproduce the issue;
3. use default window manager settings (auto-focus or -raise may avoid this problem);
4. it happens when switching back from e.g. workspace 2 to workspace 1: you click/write on the visible window but you are in fact clicking/writing on some other window in the background;
5. use maximized windows;
6. it is true that you have to click on all the entries in the taskbar (cycle through all of them?) so to make the window you want active again.

Basically, when you come back from workspace 2, workspace 1 does not show the correct window in the foreground. The "active" window is in the background. It should be possible to print "active window is %s" to show which window is active when you switch workspaces? But I don't know how window managers work, so this may not make sense.

Also, have you used valgrind or can we use valgrind during execution? How can we tweak the configuration to run marco (is marco the culprit?) under valgrind?

One more thing: @flexiondotorg says above that marco is not to blame? So, which component could be the culprit?

[jmssil]

I was having difficulties in reproducing this now that I got back to Linux Mint + MATE (even with HexChat running).

I was running marco from tty1 and got this debug output:

jmss@faust ~ $ marco --replace -d :0
Window manager warning: Log level 8: meta_display_register_x_window: assertion 'g_hash_table_lookup (display->window_ids, xwindowp) == NULL' failed
Window manager warning: Log level 8: meta_display_register_x_window: assertion 'g_hash_table_lookup (display->window_ids, xwindowp) == NULL' failed
Window manager warning: Log level 8: meta_display_register_x_window: assertion 'g_hash_table_lookup (display->window_ids, xwindowp) == NULL' failed
Window manager warning: Window 0x3c00004 (TeamViewer) sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense.
Window manager warning: Log level 8: meta_display_unregister_x_window: assertion 'g_hash_table_lookup (display->window_ids, &xwindow) != NULL' failed
Window manager warning: Window 0x3c00004 (TeamViewer) sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense.
Window manager warning: Log level 8: meta_display_register_x_window: assertion 'g_hash_table_lookup (display->window_ids, xwindowp) == NULL' failed
Window manager warning: Log level 8: meta_display_unregister_x_window: assertion 'g_hash_table_lookup (display->window_ids, &xwindow) != NULL' failed
Window manager warning: Window 0x3c00004 (TeamViewer) sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense.
Window manager warning: Log level 8: meta_display_register_x_window: assertion 'g_hash_table_lookup (display->window_ids, xwindowp) == NULL' failed

At this point I was able to reproduce the issue but the logs above probably don't refer it, I don't know.

Also:

In another experiment, I compiled marco from source using apt-get source to get the source code and ran it with valgrind. Valgrind detected some errors during execution but I was not able to analyze them since I know nothing about marco. I may try to build it again with debugging activated, do you have any hints?

[jlacroix82]

I have done some further testing. I can confirm that this problem does not occur when compositing is disabled. I am not sure at this point which compositor is being used when I did have compositing enabled. I was using the setting in Control Center > Windows > Enable software compositing window manager. When enabled, I had this issue. I haven't yet encountered this bug with that setting turned off.

[pasikarkkainen]

Yes, it seems disabling "Enable software compositing window manager" setting fixes the problem for me too! After disabling software compositing window manager I haven't seen the bug today.. (earlier it would have happened at least 10 times already).

[raveit65]

After a long period of testing i could reproduce it with default marco settings with Mate gtk3 version.
It seems that applications with 2 open windows are affected, ie. virtual-manager, here you have a main window and a window for every VM.
Sometimes the main window wasn't accessible and mouse clicks are matching the window behind it.
I think this is the issue which you're talking about?
But a restart of marco was never needed.
Mostly i could solve the issue with moving the other window.
But i never run in this issue if i enable 'auto raise + mouse sloppy' in gsettings.
And if i disabled 'org.mate.peripherals-mouse locate-pointer' than the issue wasn't to reproduce here.

[jlacroix82]

I am hoping this gets fixed very soon. I have switched away from MATE. This particular bug makes MATE too annoying to use for me. But if it gets fixed I may switch back. If there is anything I can do to test, I'll consider running MATE on one of my machines to help out.

[raveit65]

sigh,
You can simply test if enable this setting causes the issue
[rave@mother ~]$ gsettings get org.mate.peripherals-mouse locate-pointer
false
Setting this to false fixes the issue here.

[jlacroix82]

I'll try my best to test this soon.

[pilot51]

@raveit65 I've always had that false, so that setting wasn't a cause of the issue for me.

[jmssil]

@raveit65, do my comments from November 19 and 20 help in any way? Is it reasonable to add debug messages or use valgrind?

[daemonblade]

@pilot51 17-Nov-2016 comment on disabling the 'Enable software compositing window manager' made the issue go away for me.

[jlacroix82]

Disabling software compositing made the issue go away for me as well. However, that's just a work around. We should be able to have compositing without this issue. In my opinion, MATE looks terrible without compositing.

[eiginn]

I've been seeing this most often with multiple chrome windows and chrome apps. using marco with no composting does seem to work, however org.mate.peripherals-mouse locate-pointer was already false by the time i found this thread and does not appear to be doing anything for me.

Ubuntu Mate 16.04 running Mate 1.14.1 via https://ubuntu-mate.org/blog/mate-desktop-114-for-xenial-xerus/

[jlacroix82]

I finally had a chance to test the locate-pointer option. It was already set to false. I tried setting it to true, but it did not create the problem for me. Then again, this issue seemed to crop up somewhat randomly so I'm not sure exactly how to reproduce this 100%.

[the-mrd]

Same issue here with Mint Mate 18.1. locate-pointer option is disabled, need to resort to disabling compositing for the issue to go away.

[raveit65]

i'm using always this settings.
[rave@mother ~]$ gsettings get org.mate.Marco.general auto-raise
true
[rave@mother ~]$ gsettings get org.mate.Marco.general focus-mode
'sloppy'

with compositing, no issue here.

[jmssil]

I've asked a few times about ways to debug this, either by enabling some verbose mode or running the program with valgrind, but the developers simply don't answer.

I observe this now frequently in a Red Hat VM with Citrix.

[jlacroix82]

Not everyone will want to use auto-raise = true. It would be nice if we could fix this for everyone, regardless of their settings. This issue alone is preventing me from wanting to use MATE. Which is a shame, since I love MATE.

[lexfridman]

I added a small $15 bounty on this, just to contribute to Marco developers. They do an amazing job. I'm still seeing this issue in Ubuntu MATE 16.04.1.

[projectkk2glider]

Me too, Linux Mint Mate 17.3 and 18.1. Bounty of $15 added.

[jlacroix82]

MATE is my favorite desktop environment, and being unable to use it comfortably due to this bug is a real shame. I added $20 to the bounty. I know it isn't much, but I hope it helps.

[chrisamow]

Seeing this problem on Mint 18
One thing I can add is that I went to disable window compositing - by typing Windows (so I could deselect "Enable software compositing window manager" and it gave an error message box saying "window manager not supported". I killed the xserver with ctrl-alt-backsp and went into it to disable it just to make sure I am not going crazy.

4 workspaces, 2560x1600 monitor and 1920x1200 monitor

[chris-malloy-mri]

Disabling software compositing fixed the issue for me as well. Mint 18.1 MATE.

[LJBD]

The issue is also present on CentOS 7, with 2 1920x1080 monitors and 4 workspaces.
I will try to disable compositing and let you know how it went.
Also, I've looked at those settings mentioned by @raveit65 . They are different for me:

[Operator@c1 ~]$ gsettings get org.mate.Marco.general auto-raise
false
[Operator@c1 ~]$ gsettings get org.mate.Marco.general focus-mode
'click'

What does changing them do to the way MATE looks like?

[raveit65]

Also, I've looked at those settings mentioned by @raveit65 . They are different for me:

[Operator@c1 ~]$ gsettings get org.mate.Marco.general auto-raise
false
[Operator@c1 ~]$ gsettings get org.mate.Marco.general focus-mode
'click'

What does changing them do to the way MATE looks like?

[rave@mother ~]$ gsettings describe org.mate.Marco.general auto-raise
If set to true, and the focus mode is either "sloppy" or "mouse" then the focused window will be automatically raised after a delay specified by the auto_raise_delay key. This is not related to clicking on a window to raise it, nor to entering a window during drag-and-drop.
[rave@mother ~]$ gsettings describe org.mate.Marco.general focus-mode
The window focus mode indicates how windows are activated. It has three possible values; "click" means windows must be clicked in order to focus them, "sloppy" means windows are focused when the mouse enters the window, and "mouse" means windows are focused when the mouse enters the window and unfocused when the mouse leaves the window.

In short the window goes in the foreground if hover with the mouse, and gets focus if you click on it (sloppy).
Again, i use compositor.

[jlacroix82]

Having windows automatically raise when you hover over them is a completely different use-case than the one this bug was opened for. The purpose of this bug is when we click on a window, it doesn't always focus like it should. Enabling auto-raise isn't a solution or work-around, it's a different configuration. I think we should focus on the fact that clicking on a window doesn't always activate it, and not discuss the auto-raise setting because it doesn't apply here.

[raveit65]

Having windows automatically raise when you hover over them is a completely different use-case than the one this bug was opened for.

1. Looks like i am at the wrong place here :-)
2. I only answered a question
3. sorry, for all my support here......

[jlacroix82]

Looks like i am at the wrong place here :-)
I only answered a question
sorry, for all my support here......

I appreciate your support, but I was trying to keep the bug report on-task. Posting those tweaks may be useful to some people, but it has the unfortunate side-effect where someone might mistakenly think it was a fix for this issue. I think the best thing to do to help triage would be to utilize the settings from the people that are experiencing this issue, since we need to directly look at the test-case we're dealing with.

[jlacroix82]

In other news, I've discovered the following regarding this bug:

1.) Switching temporarily to Metacity rather than Marco (suggestion from Martin) eliminated this bug. Side-effect is that I cannot use the settings manager to tweak workspaces. This likely narrows it down to Marco.

2.) I am currently testing Marco with GPU compositing. So far (~2 days) the issue is gone. Not conclusive, but promising.

[flexiondotorg]

For the benefit of everyone else, Marco with GPU Compositing is an option in MATE Tweak on Ubuntu MATE that wraps Marco with Compton.

So we can further isolate the issue to compositing code in Marco.

[jlacroix82]

I will continue to test Marco with GPU Compositing and report back after enough time passes that I feel confident the issue won't come back. One drawback with Marco's GPU Compositing is that moving windows around feels sluggish, but I can live with that.

I can confirm, however, that disabling compositing altogether in Marco does eliminate the issue for me.

[jlacroix82]

Still not encountering the issue with Marco's GPU compositing. I am fairly certain I would've encountered the issue by now if it was present in this mode.

[jmssil]

How is enabling/disabling options going to efficiently help the developers find the bug?

Who are the developers? @raveit65 and @flexiondotorg ?

I asked for ways of turning on the debug messages and run marco with valgrind, but there was no answer (from the developers?).

I suppose the program must print some debug messages somehow? I suppose the code should run through valgrind without errors? I suppose we can add some criteriously placed print instructions to help debug the code?

I am about to abandon this issue, because some people here seem inclined to lead us to spend time and effort in an irrational way.

This issue is going around in circles for more than a year. I've placed clear and direct questions on how to debug this, offering my time and effort, for more than a few times. This issue is not being considered seriously and thus its existence makes no sense.

The developers are not forced to solve this. And we are, of course, much obliged for their effort in putting MATE together. But our time and expectations are as important as anyone else's.

[grisu48]

I have the same issue but could fix it by disabling the 'Enable software compositing window manager'.
Thanks to @pilot51

[djthyrax]

I was able to reproduce this problem with pluma and Geany on RHEL 7.2 in a virtualized environment with a single monitor setup - doesn't look like a problem related to Xorg/drivers.

Steps:

• Open in workspace 4 Geany and maximize it. Open pluma and size it so it uses most of your right-hand side of the screen and leave it on focus.
• Switch to workspace 1. Do some work. In a console, open a file in Geany.
• Click on the blinking Geany icon. This should take you to workspace 4. It should become inconsistent as described by pasikarkkainen, and should be corroborated if you change windows.

[jmssil]

This issue has been ignored by the developers for more than a year. Help has been offered but also ignored. I advise switching to another DE like Cinnamon, Xfce, LXDE, etc.

[pilot51]

I would advise against closing an issue just because the developers ignore it and you decide the best thing to do is switch to another DE. There is no guarantee that they will ignore it forever and while you may give up waiting, others may not. Personally, I'm fine with the workaround and was not satisfied when I last tried Cinnamon, Xfce, LXDE, GNOME 3, Unity, and KDE. It looks like only today we may finally have reliable steps to reproduce, which would help a lot if a developer decides to pick it up. Also with the bounty, I don't think those who have added to it would be happy about the issue being closed without a fix. Hopefully it doesn't open the door for someone to falsely claim the bounty.

[lexfridman]

@jmssil Please reopen the issue. I contributed to the bounty and maintain hope that it gets fixed.

[raveit65]

That we don't have a quick solution doesn't mean we ignore it.
Can someone please test if it happens with metacity?
Fedora user should use this repo https://copr.fedorainfracloud.org/coprs/yselkowitz/gnome-flashback/
And with fusion-icon you can easily switch WMs.

I advise switching to another DE like Cinnamon, Xfce, LXDE, etc.

@jmssil
Please do !

[jlacroix82]

I've already tested it with Metacity. See my earlier comment.

[raveit65]

Why is it so hard to give a answer on a simple question?
Without forcing someone to spend time to brows here.....
... we do that all in our free time without getting paid for that.

[pilot51]

Ctrl+F, type metacity, it was the only result prior to you asking about it.
In short, this issue does not exist with Metacity.

[jlacroix82]

Why is it so hard to give a answer on a simple question?
Without forcing someone to spend time to brows here.....
... we do that all in our free time without getting paid for that.

No one is asking anything of you out of the norm. I mentioned earlier that I tried this already, there's no need for me to repeat myself. If you want to assist us with squashing this bug (which would be very much appreciated), the best place to start is reading the comments that are posted here.

[muktupavels]

Not a solution, I know, but why not use Metacity if it works?

[jlacroix82]

Not a solution, I know, but why not use Metacity if it works?

It doesn't work that well, as it's not well-integrated. For example, there's no way that I know of to customize workspaces. I think it's best to fix the native MATE solution if we can.

[raveit65]

I think i found the culprit. Fedora/rhel/centos users can try those rpms.
For f26:
https://koji.fedoraproject.org/koji/taskinfo?taskID=19369066
For f25:
https://koji.fedoraproject.org/koji/taskinfo?taskID=19369224
For f24:
https://koji.fedoraproject.org/koji/taskinfo?taskID=19369240
rhel7/centos7:
https://koji.fedoraproject.org/koji/taskinfo?taskID=19369256
Others can rebuild marco from this branches.
1.16:
https://github.com/mate-desktop/marco/tree/dev-fix-251-for-1.16
1.18:
https://github.com/mate-desktop/marco/tree/dev-fix-251
...hope this helps.

[raveit65]

fixed in
master 38940ed
1.18 18e28b0
and 1.16 e1aa4ec
New releases coming soon.
Please test and blame me if you think it isn't fixed ;-)

[jlacroix82]

I apologize that I haven't had a chance to test this since the fix was implemented. I've moved on from MATE due to this bug, but now that it was fixed, I've decided to try it out. So far, I cannot reproduce this anymore. I may consider returning to MATE, I appreciate the hard work that's going into it.

[alcarola]

Hello,

I run Ubuntu 16.04.2 with the mate desktop with a dual-monitor setup and suffer from this bug, so I tried installing marco 1.16 from this ppa: https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/xenial-mate
With the new mate version, I immediately noticed that my desktop became very sluggish, taking over a second to respond to desktop changes and clicks.

Hence, I tried opening mate tweak and changing compton compositing, but I still suffer from the problem.

Any advice on how to get my desktop to stop bugging? I am reluctant to upgrading to a newer version of ubuntu, since my computer is rather old and 16.04 is a long-term-support version which works great for me apart from this bug.

Thanks for any help!

Edit: Just as I posted this, I discovered that I should try
gsettings set org.mate.Marco.general auto-raise true
gsettings set org.mate.Marco.general focus-mode 'sloppy'

so I'm now trying that. Anyway, I'd be grateful for help.

[jlacroix82]

I recommend creating a new bug report. Your behavior isn't related to this bug.

[raveit65]

I recommend to file out first a report at ubuntu at launchpad, to get ubuntu specific help ;-)

[alcarola]

What is not related to this report? The slowly responding ppa version? The OP fits my original problem perfectly.

Indeed, I guess I should ask the ubuntu people for help with finding a version of marco that works on my system. Thanks for the advice!

I have not seen the bug since I switched back to software compositing and ran those two gsetting commands, although the auto-raising of windows is rather annoying when you're not used to it.

[jlacroix82]

@alcarola Your original issue was the window ordering bug mentioned in this report, however, that was solved already and a commit was created to fix it. If you have issues that start after installing a PPA, then your problem is with the PPA. Therefore, a bug report should be filed there.

[alcarola]

Indeed, thanks! :)

[owensss]

I have the problem discribed at #257 and the fix don't work for me.
the two issues seems alike and perhaps have a same cause

$ marco --version
marco 1.18.1

[naturally-intelligent]

I keep running into this too, Ubuntu MATE 16.04, using Compiz. I don't know the cause, but last time it happened, it was from the standard popup after inserting a DVD.

To fix it in session, I opened Compiz Config -> General Options -> Focus & Raise, then turn on Auto-Raise, poke around, then turn it back off. Works for me without having to lose session - BUT - some windows seem to retain the unwanted behavior until interacted with twice.

[raveit65]

Please file out a report against compiz at your distro.

[jlacroix82]

I keep running into this too, Ubuntu MATE 16.04, using Compiz. I don't know the cause, but last time it happened, it was from the standard popup after inserting a DVD.

This bug was fixed in newer versions of MATE. Since Ubuntu MATE 16.04 is locked at an older version of MATE, it will not receive the fix for this. The only solution is to upgrade to a newer version of the distro.

There is a work-around, where you can try to change between software and hardware rendering in MATE tweak. One of them should stop this from happening, but I can't remember which.

[raveit65]

This bug was fixed in newer versions of MATE. Since Ubuntu MATE 16.04 is locked at an older version of MATE, it will not receive the fix for this. The only solution is to upgrade to a newer version of the distro.

There is a work-around, where you can try to change between software and hardware rendering in MATE tweak. One of them should stop this from happening, but I can't remember which.

The guy use compiz WM, not marco :-)

[jlacroix82]

The guy use compiz WM, not marco :-)

Ah, good point! For some reason, I forgot that those were separate.

I agree with raveit65, if you're using Compiz, file a bug against Compiz.

It may be useful to test a newer version of Ubuntu MATE to see if this has already been addressed. Keep in mind, 16.04 is approaching two years old now.

[naturally-intelligent]

This bug has come back to me even with the new NVIDIA drivers.

Same solution as above to save working session. (Compiz Config -> General Options -> Focus & Raise, then turn on Auto-Raise, poke around, then turn it back off.)

[spook]

And still there for Ubuntu 17.04 with marco 1.18.0, with or without the new NVIDIA drivers.
The workaround of disabling "software compositing window manager" still gets around the problem.

[raveit65]

And still there for Ubuntu 17.04 with marco 1.18.0, with or without the new NVIDIA drivers.
The workaround of disabling "software compositing window manager" still gets around the problem.

Are you shure 17.04 use this fix or is your post more a blind-post (date)?

[raveit65]

This bug has come back to me even with the new NVIDIA drivers.

Same solution as above to save working session. (Compiz Config -> General Options -> Focus & Raise, then turn on Auto-Raise, poke around, then turn it back off.)

Did you blame nvidia for this?
https://devtalk.nvidia.com/