Firefox "Open Containing Folder" doesn't open caja in foreground

[rogue-spectre]

Hi,

Test on linux mint mate 17
marco 1.10.2
caja 1.10.3

I noticed that after downloading a file in a maximised Firefox windows opened via an icon, if one wants to use the "Open Containing Folder" caja is open in the background. The corresponding box name in mate panel is bold. (that's not a nice behaviour ;)). Now if one keeps Firefox open, get caja in the foreground and close it, cliquing again on "Open Containing Folder" opens caja in the foreground.

If one does the same thing but opening Firefox in a terminal or in a minimized window caja opens in the foreground (that's the user friendly behaviour).

I think that the problem comes from the window manager but i could be wrong. On Xubuntu 16.06 the behaviour is correct "Open Containing Folder" does what the user thinks, it opens the file manager in the foreground, On Ubuntu 16.06 the file manager is open in the background.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[sc0w]

there is a bounty here, currently 10$

https://www.bountysource.com/issues/35571687-firefox-open-containing-folder-doesn-t-open-caja-in-foreground

[y7x]

This bug still exists with Linux Mint 18.3 MATE, Linux Mint 19 MATE Beta, Ubuntu 18.04 MATE and Fedora 28 MATE Compiz. Meaning it's still in up to caja 1.20.1 and marco 1.20.1
I noticed that the problem rogue-spectre described goes away shortly, if you kill caja. If you then press "open containing folder" in firefox again, the window opens in the foreground again and any future caja windows through "open containing folder" will open like that as well as long as you only move, minimize or maximize the caja windows. As soon as you do anything else in a caja window like clicking into the window (not the border), select a file / folder, click on the file menu, closing the caja window etc, any future caja window will open in the background again.
Hope this helps someone narrow in on the source of the bug.

[lukefromdc]

Confirmed here-and also found this happens only in Marco and not in compiz-reloaded (at least not from my branch and probably not any branch). If I "open containing folder" in compiz with my settings there (in ccsm), I get the Caja window focusses and centered too. In Marco it comes up under Firefox and with Firefox's window centered also enough below it that I can see the bottom of it to bring it up. This was confirmed by a compiz-marco-compiz window manager switch, retesting the FF "open containing folder" option each time.

OK, the question is this: what is Firefox doing that compiz is catching and marco is not?

[vkareh]

@lukefromdc - these are brand new issues and they seem somehow related: #411 and #412

[lukefromdc]

Brand new issues: when did they start? If you are building from source, you might be able to bisect to find the exact commit that introduced the problems. If using binary packages, if you stil have older versions you can progressively roll back to older versions one version (out of what you have around) at a time until you find a version where the problems do not appear. From that version and the first one you have with the problems, a range of problem commits is thus identified as containing the culprit. That makes a bisect by someone else a lot easier.

[y7x]

Just tested it in Linux Mint 17. The bug's is already in MATE 1.8 but slightly different. If you close a caja window on 1.8, the first new caja window actually works correctly again. All following windows popunder again.

[y7x]

and the bug doesn't appear for me in Linux Mint 16 MATE, which has caja 1.6.2 and marco 1.6.2 so I guess it's between MATE 1.6 and 1.8 where it was introduced.

[lukefromdc]

MATE 1.6 is GTK2-only, meaning that my currrent build environment (MATE 1.20/1.21, gtk3-only ) cannot build and run, thus cannot bisect MATE versions that old. This is because gtk2 and gtk3 symbols cannot be mixed, and my build environment is bare metal on my working desktop

[lukefromdc]

@monsta , @vkareh, @raveit65 , any ideas here?

[raveit65]

1.6 or 1.8 are from old debian or LMDE boxes, where are those maintainers?

[lukefromdc]

This was said to still exist in MATE 1.20, and indeed I have confirmed it myself in git master. Looks like an old issue that we still have. Next question would be does this occur in Metacity, because if not there might be a commit which addressed this that could be ported over.

[raveit65]

This was said to still exist in MATE 1.20,

I know , and i have confirmed it for myself, but we need someone which have old software like debian or LMDE with mate-1.6-1.8 to bisect.

[y7x]

Can you guys give me any pointers as to what software I need to build to make these builds between marco 1.6 and 1.8 run, if I can even help? I think I can set up any VM that is needed.
Is it possible from any distro which is based on MATE 1.6? Because I started bisecting on a LM16 VM (I just learned a bit of git) and built a version at commit 6f4ee23 but on doing ./src/marco --replace I get:
(marco:19072): GLib-GIO-ERROR **: Settings schema 'org.mate.Marco.general' does not contain a key named 'side-by-side-tiling' Trace/breakpoint trap
I don't know if other parts of MATE need newer builds as well to work with this version of marco or what's exactly the way to do this right now. So I'd be glad for some reassurance that I'm at least delving in the right direction.

[y7x]

I was able to get marco to run by copying the respective xml from /usr/share/glib-2.0/schemas/org.mate.marco.gschema.xml from a LM18 install to the LM16 VM and compiled the xml files into a new gschemas.compiled file in the same folder with glib-compile-schemas .
marco ran, but the bug was still there. I failed some more at commits between MATE 1.6 and 1.8 but got multiple builds to run around commit a871571 where I got confused when I found that the bug still appeared. I then tested the normal installed marco (v.1.6.2) from LM16 for a sanity check and it displayed the bug too! I tested a clean LM16 VM again and the bug didn't appear, as I first mentioned in my 3rd post on this bug.
That's when I noticed that I unintentionally upgraded Firefox 24 on the first LM16 VM to Firefox 30. I found out that the bug appears only with Firefox 28.0 and higher (I tested 60.0 too for example). Firefox 27.0 / 27.01 etc and lower don't show the bug as far as I know.
So of course I tested this not only on LM16 (MATE 1.6.2) but on higher and lower MATE versions.
Result: Firefox 28.0 and higher show the bug also on MATE 1.18 (LM 18.3).
But on LM14 (MATE 1.4.1) ALL Firefox versions work. So I started bisecting between MATE 1.4.1 and MATE 1.6.2 to find the commit where Firefox versions 28.0 and higher start showing the bug with caja.
I was able to build down to commit 7f59518 sucessfully where Firefox 28.0 and higher are buggy. Commit 891fd1a was the last one where I was able to build marco. Between these two commits I got autoconf errors à la:
You should update your 'aclocal.m4' by running aclocal. Running aclocal-1.11... configure.in:496: warning: macro 'AM_MATECONF_SOURCE_2' not found in library
I'll take a look a those later, just wanted to update. And since marco 1.4.1 (which I have on LM14) should be from commit d4b4416, there should only be 5 more commits to test.

[y7x]

Ok, so I just said that I was able to build down to commit 7f59518 successfully. With that I meant being on LM16 (MATE 1.6.2), getting a marco 1.5.0 build to run but the bug appeared. I also built the same commit but on a LM14 VM (MATE 1.4.0) and can't produce the bug like that. This makes me think something circumstantial in MATE 1.6.2 causes the bug and maybe not marco. Caja comes to mind of course, so I tried to get caja 1.4.0 to run on LM16. I had to copy libmateconf-2.so.4 and libMateCORBA-2.so.0 from /usr/lib to the LM16 since they don't exist there. Caja runs there like that and spews lots of errors but if you kill the caja 1.6.2 process first, you can get firefox (a version >27 is relevant here since lower works anyway) to open caja 1.4.0 and it doesn't appear to have the bug. This is all extremely unclean obviously, but it's the only indicator for me at the moment.
So now I'll start bisecting between caja 1.4.0 and 1.6.2 on LM16 to see if I get a higher version of caja to produce the bug.

[raveit65]

I had also weird results.
I used centos7 VM with mate-1.16 (gtk2).
First i tested firefox with very old metacity-2.34.13-7.el7.x86_64. Here the first click on the Open Containing Folder opens the caja window in the background. But after closing this caja window, next click on the Open Containing Folder opens the caja window in foreground.
Ok, now bisceting caja gives me that commit as culprit.
49d8304
A backport from newer metacity.
So, reverting that commit in marco-1.16.1 gave me same behavior like metacity in centos7 VM with firefox-52.8.0-1.el7.centos.x86_64.

Then i reverted the commit in f28 with marco from master (1.21.0) and i got same results first.
But after i played a bit around with disable/enable several gsettings keys of marco everything works out of box without reverting the commit.

[rave@mother ~]$ gsettings get org.mate.Marco.general auto-raise
true
[rave@mother ~]$ gsettings get org.mate.Marco.general focus-mode
'sloppy'
[rave@mother ~]$ gsettings get org.mate.Marco.general raise-on-click
true

Now the first click on the icon opens the caja window in foreground with firefox-60.0.2-1.fc28.x86_64, which is weird.
Sorry, no idea what really happens here...
Edit:
It doesn't work out of box without reverting the commit.

[raveit65]

Ok, i tested it again on a new day.
With marco-1.21.0 and the commit reverted + disabling this gsettings key

[rave@mother ~]$ gsettings get org.mate.Marco.general raise-on-click
false

the behaviour is like old metacity-2.34.13-7.el7.x86_64

1. first click on the Open Containing Folder opens the caja window in the background.
2. After closing this caja window, next click on the Open Containing Folder opens the caja window in foreground.

This is the revert patch

From cdc7d2e19cbe64e20b702bf0d8f04ec2e376c65f Mon Sep 17 00:00:00 2001
From: raveit65 <mate@raveit.de>
Date: Sun, 24 Jun 2018 12:38:45 +0200
Subject: [PATCH] Revert "window: load NET_WM_USER_TIME from the right window"

This reverts commit 49d830417d9ef75241eb63d6d08a51603cfda18f.

Test : partial fix for https://github.com/mate-desktop/marco/issues/278
---
 src/core/window.c | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/src/core/window.c b/src/core/window.c
index 44084a0..8cddcfb 100644
--- a/src/core/window.c
+++ b/src/core/window.c
@@ -5696,8 +5696,6 @@ static gboolean
 process_property_notify (MetaWindow     *window,
                          XPropertyEvent *event)
 {
-  Window xid = window->xwindow;
-
   if (meta_is_verbose ()) /* avoid looking up the name if we don't have to */
     {
       char *property_name = XGetAtomName (window->display->xdisplay,
@@ -5708,13 +5706,7 @@ process_property_notify (MetaWindow     *window,
       XFree (property_name);
     }
 
-  if (event->atom == window->display->atom__NET_WM_USER_TIME &&
-      window->user_time_window)
-    {
-      xid = window->user_time_window;
-    }
-
-  meta_window_reload_property_from_xwindow (window, xid, event->atom, FALSE);
+  meta_window_reload_property (window, event->atom, FALSE);
 
   return TRUE;
 }
-- 
2.17.1

[y7x]

@raveit65 I read what you found out and noticed that this commit 49d8304 is from between marco 1.10 and marco 1.12. So I started comparing two MATE environments: LM17.2 (MATE 1.10) and LM17.3 (MATE 1.12).
In each VM I tested different window managers and how it affected the bug we're trying to solve.
There are a few distinct behvaiours while triggering the bug, that I noticed.
When you open a caja window through Open Containg Folder in Firefox the window appears in the background or in the foreground for a couple different reasons.

It appears in the background because either:

• It's not the first caja window to be opened, and e.g. clicking on something in the earlier caja window "poisoned" (for lack of a better word) the caja process for all future windows.
• The last caja window that was open before the whole process was killed (pkill caja), was maximised, leading to the first new caja window opening correctly but poisoning the process thereby for the following windows.

It appears in the foreground because either:

• The caja window is the first one to be opened from firefox so that the caja process isn't poisoned yet.
• A caja window was closed or minimised just a moment before, which "unpoisoned" the caja process allowing the next caja window to open properly in the foreground.

Now to the differences I recorded between the MATE versions and the different window managers.
LM17.2 ~ MATE 1.10
marco 1.10.2:

• Closing the last caja window, that just got opened, results in the next opened caja window to always appear centered and in the foreground. Further caja windows are poisoned again and appear on the last remembered position in the background.
• Closing older caja windows, whether they appeared centered and focused or in the background, doesn't seem to matter. Closing them doesn't consistently unpoison the process, just sometimes.
• Minimising a caja window that got unpoisoned by an action just before results in the next caja window being unpoisoned as well.
• Poisoned caja windows can be unpoisoned inconsistently by clicking into the window first and then minimising them.

Compiz 0.9.11.3:

• Bug appears but unpoisoning caja doesn't seem to be possible in any way with minimsing / closing.

LM17.3 ~ MATE 1.12
marco 1.12.0:

• Same as marco 1.10.2 but no unpoisoning possible.

marco 1.12.1 ~ reverted commit 49d8304:

• Shows same behaviour as marco 1.10.2 with unpoisoning possible with close / minimise.

I guess that means you found that commit that took away the unpoisoning ability. Changing the gsettings key of raise-on-click to false didn't seem to change anything for me. I didn't test it extensively though.
What I saw in the description of this key in the dconf-editor is this though:Setting this option to false can lead to buggy behavior, so users are strongly discouraged from changing it from the default of true.. So I don't know what to make of this.
Are you sure that you killed caja before opening it again through Open Containing Folder? Because if you accidentally left it poisoned, that would explain the difference in behaviour you found compared to me as the first caja window always opens in the foreground for me (after pkill caja).

metacity 2.34.13:

• Seems to behave like marco 1.10.2 on LM17.2.

compiz 0.9.11.3:

• Like on LM17.2, no unpoisoning possible.

--

I always restarted the virtual machines after changing the window manager as the unpoisoning behaviour wouldn't change otherwise.
While doing these tests, I was also wondering what the intended behavior actually was when clicking Open Containing Folder. I guess the caja window should always appear focused and centered, or should it appear where already existing caja windows are?

Anyway, this just showed that the bug appears with window managers other than marco (although slightly different). That's why I tested this also with the Thunar 1.6.11 file manager and nautilus 3.10.1 on LM17.3 with marco 1.12.0. They both don't have the bug. That's why I'm still pretty convinced that there was some bug introduced between caja 1.4 and 1.6 like I mentioned in my last post. I still can't get these versions to build though since I'm stuck at these autoconf errors configure.in:496: warning: macro 'AM_MATECONF_SOURCE_2' not found in library and would appreciate some help with that.

[raveit65]

I still can't get these versions to build though since I'm stuck at these autoconf errors configure.in:496: warning: macro 'AM_MATECONF_SOURCE_2' not found in library and would appreciate some help with that.

MATECONF = GCONF
I don't think that it is possible to build caja with mateconf config system against the rest of mate desktop which use gsettings.
Mateconf was very early replaced with gsettings.
For using mateconf you need to downgrade mate-desktop-libs package too.
But most other packages are depending on mate-desktop.

[elcste]

I noticed recently that the "Show in File Manager" command of the music player Quod Libet also gives this wrong behavior, so it's not just Firefox.

[testman42]

Anything new in regards to this issue?

[balazs-endresz]

If I add meta_window_focus (window, meta_display_get_current_time_roundtrip (window->display)); here: https://github.com/mate-desktop/marco/blob/v1.26.0/src/core/window.c#L5239 then the newly opened window (e.g. caja from firefox, or subl . from the terminal) takes focus and opens in the foreground correctly but only if it's set to open maximised.

When using mate-netbook if I add the app that is being opened to /org/mate/maximus/exclude-class then this function (meta_window_client_message) is not even called.