Created attachment 6172 [details]
Mate desktop.

Note: it's no use just running Caja, for the problem does not arise that way.

This bug is related  to #15601. Unlike other desktops, like old good Gnome2, Caja (nautilus fork) manages whole desktop. So, starting it somehow makes Caja to manage the KDE Desktop. This is not desired behavior. I'll investigate that...

CC: (none) => tarakbumba

BTW, do you see same behavior with Cauldron or is this specific to Mageia 4 and Mate 1.6 ?

I actually wanted to test it in Cauldron, having observed it first in Mageia 4.

But in Cauldron, Caja cannot be launched (as documented in bugs 15601 and 15577).

So, objectively answering your question, the same behaviour occurs in part -- Firefox uses Caja, but since Caja dies, the second part does not happen (the Alt-Tab part).

Kinda off-topic from now on:

If you will work on that, please note that even without Mate interference, I find Alt-Tab behaviour weird (this will be reported later in another bug):

1) Log into KDE;
2) Have the "always show desktop icon" on (it's in KDE's "Window Behaviour")
3) Open some tasks (terminal, kpat etc.)
4) Switch with Alt-Tab to Show desktop... result: all windows minimized;
5) Switch with Alt-Tab to Show desktop... result: all windows restored.

4 & 5 look conflicting to me. Windows has an equivalent shortcut (Super/Win-D), but unless I misunderstood things "Show desktop" should, uh, show the desktop. Or perhaps someone should rename it "Toggle desktop view". Or is it a translation problem?

Please ignore the OT part above, because Windows does the same, so it might be a feature.

I can not confirm desktop part on my fully updated Mageia 4 x86_64 Mate/Kde install VM. Bug#15601 is confirmed. Indeed firefox tries to opens caja, instead of dolphin. But Alt+Tab does not changed background or icons. It is all the same KDE desktop. So, i think this is something with your KDE config. Can you reproduce same Alt+Tab behavior with a new user?

Yes, it was possible, though not easy.

First of all, I naively let Firefox be updated to 31.6.0 (but then it's a production machine); Caja remained at 1.6.3.

I then created a new user.

With the new user in KDE I used Firefox to download a file (to ~/Downloads/)... then clicked on "FF download arrow"/Show all downloads and click in the little folder icon to open it.

Caja opened and crashed, just like it is doing in Cauldron.  It's all too fast, I had to use journalctl -f to see its starting message -- strangely, no error messages afterwards. And the Alt-Tab bug was not reproducible.

I then went to the normal user, tested the problem and it still happened as reported -- and Caja works normally without crashing.

Back to the new user, I tried things like "marco --replace" and "kwin --replace" because I've done that with the old user; logged with the new user into Mate and then back into KDE. Still no bug.

Finally, I managed to reproduce the bug in a slightly different way with the following steps:

1. Create a new user with MCC/System/Users...
2. End session and log back into KDE with the newly created user.
3. Change KDE's screen background (there's a stripes pic available).
4. In Systemsettings/Window behaviour, turn on the option [Always show "Show desktop" icon].
5. Open a Konsole terminal.
6. Run "caja --sync" (it is expected to open and work, even if "caja" alone crashes).
7. Close the caja window.
8. Notice the Konsole window does NOT show a prompt: something is still running.
9. Verify with Alt-Tab that the bug is ocurring (no need to use FF).
10. If you wish, do the Firefox thing and confirm it opens Caja to show the download folder.
11. Go back to Konsole and press Ctrl-C to end whatever is running there.
12. The bug disappears (if Mate desktop is shown, it returns instantly to the KDE one).
13. FF again tries to open Caja and it crashes (like before I started Konsole).

With my normal user, I believe something is activating whatever "caja --sync" activates -- which makes Caja no longer crash and causes the present bug.

It can therefore be seen that the bug is related to some condition which arose in my normal user account and is not present in other users; maybe that alone is reason enough to declare this bug INVALID.

That the bug can be triggered by some special uncommon command ("caja --sync") is an indication of a problem. In any case, as soon as Caja is updated as noted in bug 15577 , Firefox should no longer call Caja in KDE and thus, I expect, the bug won't occur even if some unfortunate user happens to do whatever I did in my normal account.

Atilla, thanks and please keep up the good work.

Renato, please look at bug#15577#c4

Attila,

With updated package, Caja no longer crashes. It opens regularly when called from Konsole and can be closed as any other application. Also, "caja --sync" works the same way as simply running "caja" -- no messages, no errors.

All is perfectly fine, except that Firefox keeps on using Caja instead of Dolphin (which is bug 15601 ).

But you were successful in eliminating the present bug: that alternating desktop when using Alt-Tab no longer occurs with the new user. I shall still test it with my normal user.

Ok, the Alt-Tab bug no longer occurs in my normal user, too.

As far as I am concerned, what the present bug refers to has been fixed by your patch.

The problem of Firefox calling Caja in KDE still remains; I did file a bug about it but it was about Cauldron not Mageia 4 (bug 15601 ).

I don't know what is your opinion about that; if you wish so, I can file another bug for Mageia 4 just like the one about Cauldron (it's just copy&paste in fact, but maybe focusing in Cauldron is a better strategy... I think you guys must be overworked). Also, if you wish to close this one, I think it's ok -- the reported bug was fixed IMHO.

Please see bug 15577 on why I didn't close that one.

Attila, thanks for the good work.

Thank you Renato. I' m preparing an update advisory for this. There is no need to duplicate bug#15601. I' ve changed it to reflect Mageia 4 too.

Hardware: i586 => All

I have uploaded a patched mate-file-manager package for Mageia 4.

Suggested advisory:
========================

Updated mate-file-manager packages fix two issues:

When users installed mate-file-manager on KDE Desktop, mate-file-manager tries to handle desktop management and crashes. Also, because it tries to handle desktop management it breaks plasma desktop and shows a Mate/KDE mixed desktop view randomly. Note that the second issue is not valid for all users.

This update fixes these two issues via backported one patch from upstream that disabling mate-file-manager's desktop management feature on non Mate desktop environments.

References:
https://github.com/mate-desktop/caja/commit/23b75dadd35f039a8cd93111528a8a66dde8888e
https://github.com/mate-desktop/caja/issues/304
https://bugs.mageia.org/show_bug.cgi?id=15604
https://bugs.mageia.org/show_bug.cgi?id=15577

Test Case:
========================
1- Install mate-file-manager and deps on a KDE Deskop machine,
2- Try to run "caja" from Konsole and see that it crashes.
3- Try to return to desktop view using Alt+Tab. You may see that desktop view is messed as a Mate/KDE mix.

Updated packages in core/updates_testing:
========================
mate-file-manager-1.6.3-1.2.mga4
libcaja-extension-devel-1.6.3-1.2.mga4
lib64caja-extension-devel-1.6.3-1.2.mga4
libcaja-extension1-1.6.3-1.2.mga4
lib64caja-extension1-1.6.3-1.2.mga4
libcaja-gir2.0-1.6.3-1.2.mga4
lib64caja-gir2.0-1.6.3-1.2.mga4


Source RPMs:
======================== 
mate-file-manager-1.6.3-1.2.mga4.src.rpm

Assignee: bugsquad => qa-bugs
Source RPM: (none) => mate-file-manager-1.6.3-1.1.mga4

Erm, Attila, do you think this new patch could somehow change KDE (or that xdg thing) file associations?

I ask because I opened an external USB HD with "Open with file manager" and I got Audacious (with a xmms-like UI)...

In KDE System Settings / File associations there's a "inode" entry with "mount-point" and "directory" sub-entries, both with Audacious on top (I moved it to bottom manually); in Cauldron, Dolphin is correctly at the top.

Also, I have fortunately a Mageia 4 x86_84 still not updated (it's on 1.1.mga4) and such entries have Dolphin at the top.

I'm sure I would have reported that if I saw it happen...

Hi, I found these two (one is duplicate of the other):

Bug 7802
Bug 10117

Seems to be a regression.

No, the new patch doesn't interfere with mime type associations. That should be something with shared-mime-info or audacious. I think you should comment this to bug#10117

Done, though I had no info on that bug.

Testing mga4 64 as comment 13

Possible problem Atilla. Renato does this fix the issues you were having?

Before
------
$ caja

** (caja:24993): WARNING **: Failed to get the current CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files
The program 'caja' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 7 error_code 9 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


After
-----

First time it's started this way it shows some warnings for various file formats as it creates previews. Closing caja shows some errors and doesn't seem to end the process, so it has to be killed with ctrl-c.

Starting it a 2nd time skips the preview warnings but and when closing still shows the errors and has to be killed with ctrl-c, as below..

$ caja

** (caja:26844): WARNING **: Failed to get the current CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files

(caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x2661ee0' has no handler with id '1436'

(caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x26e0240' has no handler with id '1015'

(caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x26e1e60' has no handler with id '1022'

(caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x2678f40' has no handler with id '1029'

(caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x26e04c0' has no handler with id '1002'

(caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x7f6b1c001760' has no handler with id '1008'

(caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x26f2800' has no handler with id '3264'
^C

(In reply to claire robinson from comment #18)
> Testing mga4 64 as comment 13
> 
> Possible problem Atilla. Renato does this fix the issues you were having?
> 
> Before
> ------
> $ caja
> 
> ** (caja:24993): WARNING **: Failed to get the current CK session:
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.freedesktop.ConsoleKit was not provided by any .service files
> The program 'caja' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
>   (Details: serial 7 error_code 9 request_code 53 minor_code 0)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error() function.)
> 
> 
> After
> -----
> 
> First time it's started this way it shows some warnings for various file
> formats as it creates previews. Closing caja shows some errors and doesn't
> seem to end the process, so it has to be killed with ctrl-c.
> 
> Starting it a 2nd time skips the preview warnings but and when closing still
> shows the errors and has to be killed with ctrl-c, as below..
> 
> $ caja
> 
> ** (caja:26844): WARNING **: Failed to get the current CK session:
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.freedesktop.ConsoleKit was not provided by any .service files
> 
> (caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x2661ee0'
> has no handler with id '1436'
> 
> (caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x26e0240'
> has no handler with id '1015'
> 
> (caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x26e1e60'
> has no handler with id '1022'
> 
> (caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x2678f40'
> has no handler with id '1029'
> 
> (caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x26e04c0'
> has no handler with id '1002'
> 
> (caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance
> '0x7f6b1c001760' has no handler with id '1008'
> 
> (caja:26844): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x26f2800'
> has no handler with id '3264'
> ^C

I think this is a problem with also nemo. I have installed both nemo and nautilus on KDE on Mageia 5 RC9. So, this issue is Cauldron TOO. Nemo still runs after closed from gui. The warnings you saw with caja is irrelevant with the issue i think.

The problem for Caja comes from default Caja settings. Unlike KDE or GNOME3 or XFCE, the desktop and automounts are handled by caja. Thus caja must be run as a daemon mode in order to volume/cd/dvd mounts in MATE. So, it does not exit when last caja window closed.

I'm currently working on a patch to disable daemon mode on Desktops other than MATE. Hope that fixes this issue.

Hi, Claire and Attila,

Ok, it seems I messed up by having not tested it as completely as I could.

I also misled Attila to believe it was solved when I only made sure it worked on M4 586 and Cauldron 586. Sorry, my bad.

Well, in my notebook which is actually used by my wife and kid, I've noticed this bug is unfortunately not completely solved as comment 11 would lead one to believe.

This is the present situation over here:

- in Cauldron 586 with Caja 1.8.2 (caja 1.8.2 3.mga5), Caja does not crash ( bug 15577 ), bug 15601 occurs (Firefox uses Caja) and the present bug does not occur (Caja does not take control of the KDE desktop).

Direct execution of Caja in Konsole looks normal, the Caja window opens and the bash prompt in Konsole is shown immediately after the file manager window opened. Closing Caja and thereafter closing Konsole yields no error message.

- in Mageia 586 with Caja 1.6.3 (mate-file-manager 1.6.3 1.2.mga4), Caja does not crash ( bug 15577 solved ), bug 15601 occurs (Firefox uses Caja) and the present bug does not occur (Caja does not take control of the KDE desktop).

Direct execution of Caja in Konsole looks like the attached picture ("Cja without Firefox"). As can be seen, some commands are started ("caja-open-terminal" and "caja-image-converter") -- this was happening before when the bug still occurred, too -- and the Caja window opens; the bash prompt is not shown. Closing the file manager window and then trying to close Konsole yields a dialog stating there's a program still running ("Caja") and prompting for termination. If we hit Cancel and press Ctrl-C in Konsole, Caja finally ends and Konsole can be closed without any further message.

This can be repeated as wished and the depicted messages come up everytime.

The funny things is Firefox cures that: after using FF in the manner described at the start of this bug (download file, click on arrow and then on tiny open download folder icon), caja will run in Konsole without those messages.

Direct execution of Caja in Konsole now becomes normal, the Caja window opens and the bash prompt in Konsole is shown immediately after the file manager window opened. Closing Caja and thereafter closing Konsole yields no error message.

- in Mageia x86_64, things are pretty much what they were, because I'm not using the "updates testing" repo here. I will try to configure it and see if Caja is updated.

For now, I have the package mate-file-manager 1.6.3 1.1.mga4 (the old one); with it, Caja does crashes ( bug 15577 ), bug 15601 occurs (Firefox uses Caja) and the present bug does occur (Caja takes control of the KDE desktop -- using "caja --sync" to test). It's a toggle thing: press Alt-Tab to get to the other desktop.

These are errors I get (I posted them on bug 15577, but here they are again for convenience... I didn't copy from that bug, these are the just now shown messages):

===============================================
[zz@localhost ~]$ caja
Initializing caja-image-converter extension
Initializing caja-open-terminal extension
The program 'caja' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 7 error_code 9 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[zz@localhost ~]$
===============================================
Using caja --sync as suggested allowed me to see Caja's version. "caja --sync" does not produce error messages:

===============================================
[zz@localhost ~]$ caja --sync
Initializing caja-image-converter extension
Initializing caja-open-terminal extension
^C
[zz@localhost ~]$
===============================================

Claire, answering your question, none of those "GLib-GObject-WARNING" messages were displayed (nor did they appear in jounalctl -f).

I will try now updating.

Created attachment 6353 [details]
Caja ran directly without using Firefox first to call it.

I had to select Core Updates Testing (distrib 5) and nothing was there for updating; then I "added" repositories and it found another Core Updates Testing (distrib50). Then the version with the fix appeared ( 1.6.3 1.2.mga4),

After updating, things are much like in the 586 version described above (this rimw I actually copied):

- with Caja 1.6.3 (mate-file-manager 1.6.3 1.2.mga4), Caja does not crash ( bug 15577 solved ), bug 15601 occurs (Firefox uses Caja) and the present bug does not occur (Caja does not take control of the KDE desktop).

Direct execution of Caja in Konsole looks like the attached picture ("Cja without Firefox"). As can be seen, some commands are started ("caja-open-terminal" and "caja-image-converter") -- this was happening before when the bug still occurred, too -- and the Caja window opens; the bash prompt is not shown. Closing the file manager window and then trying to close Konsole yields a dialog stating there's a program still running ("Caja") and prompting for termination. If we hit Cancel and press Ctrl-C in Konsole, Caja finally ends and Konsole can be closed without any further message.

This can be repeated as wished and the depicted messages come up everytime.

The funny things is Firefox cures that: after using FF in the manner described at the start of this bug (download file, click on arrow and then on tiny open download folder icon), caja will run in Konsole without those messages.

Direct execution of Caja in Konsole now becomes normal, the Caja window opens and the bash prompt in Konsole is shown immediately after the file manager window opened. Closing Caja and thereafter closing Konsole yields no error message.

In case of any other thing, please just drop me a line.

Thanks everyone for the hard work.

I have uploaded a patched mate-file-manager package for Mageia 4.

Suggested advisory:
========================

Updated mate-file-manager packages fix an issue:

When a user tries to run Caja (mate-file-manager) from commandline on a KDE or any DE apart from MATE; caja doesn't exists even the last caja window is closed.

The problem for Caja comes from default Caja settings. Unlike KDE or GNOME3 or XFCE, the desktop and automounts are handled by caja. Thus caja must be run as a daemon mode in order to volume/cd/dvd mounts in MATE. So, it does not exit when last caja window closed. This behaviour may be changed by modifying caja preferences using dconf-editor or directly gsettings (org.mate.caja.preferences/exit-with-last-window option set to true)

Since, Destop Environments other than MATE doesn't rely on Caja's automounting feature; this setting always should be "true" for them. This update adds a patch which sets exit-with-last-window option value to true for other desktops.

References:
https://git.gnome.org/browse/nautilus/commit/?h=gnome-2-32&id=3d8011ca8c095be884b603ccea261b955fa6518b
https://git.gnome.org/browse/nautilus/commit/?h=gnome-2-32&id=ba6a7c6e1098c5cb88fb7468e98bf9f58ff6b543
https://github.com/mate-desktop/caja/pull/409
https://bugs.mageia.org/show_bug.cgi?id=15604#c19

Test Case:
========================
1- Install mate-file-manager and deps on a KDE Deskop machine,
2- Try to run "caja" from Konsole and see it doesn't exit altough last caja window is closed.
3- Install updated package and logout/login again to KDE Desktop.Try to run "caja" from Konsole and see it exists after last window is closed. You may see some warnings but that's ok.

Updated packages in core/updates_testing:
========================
mate-file-manager-1.6.3-1.3.mga4
libcaja-extension-devel-1.6.3-1.3.mga4
lib64caja-extension-devel-1.6.3-1.2.mga4
libcaja-extension1-1.6.3-1.3.mga4
lib64caja-extension1-1.6.3-1.3.mga4
libcaja-gir2.0-1.6.3-1.3.mga4
lib64caja-gir2.0-1.6.3-1.3.mga4


Source RPMs:
======================== 
mate-file-manager-1.6.3-1.3.mga4.src.rpm

Hi, Claire and Attila,

I just got caja 1.8.2- 4.mga5 on Cauldron... now it runs in KDE like this:

=========================================
[zz@localhost ~]$ caja
Initializing caja-open-terminal extension
Initializing caja-image-converter extension

(caja:25208): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

--- Hash table keys for warning below:
--> zz
--> l2054
--> inode/directory
[zz@localhost ~]$
=========================================

I don't even understand what is the warning below (is the one above?)

The good part is that Firefox is doing the right thing and opening the download folder with Dolphin. A minor problem (which might be entirely coincidental) is that Dolphin took a loooooooooooooooong time to open in the first time (looking like Thunar when run the first time on a system). By long I mean something around 10 seconds (usually it takes 1 second).

Changing directory leads to little change:

=========================================
[zz@localhost tmp]$ caja .
Initializing caja-open-terminal extension
Initializing caja-image-converter extension

(caja:27190): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

--- Hash table keys for warning below:
--> inode/directory
--> zz
--> root
--> l2054
--> l31
[zz@localhost tmp]$
=========================================

/tmp was chosen because it is outside my user's home but still readable somewhat.

Anything you might want to know, please drop a line...

Thanks for the good work.

Thanks Renato. Those warnings are completely ok. Seems that caja now properly exits. Would you mind to test on Mageia 4?

Caja exits in Cauldron, but in Mageia 4 things remain the same -- I only got an update for Caauldron for the moment...

When it happens, I'll test it.

(In reply to Renato Dali from comment #26)
> Caja exits in Cauldron, but in Mageia 4 things remain the same -- I only got
> an update for Caauldron for the moment...
> 
> When it happens, I'll test it.

You should enable core/updates_testing repository in order to get mate-file-manager-1.6.3-1.3.mga4. It should already uploaded yesterday. You may not see that if your mirror is out of sync.

Well, Cauldron was updated; don't know whether it uses the same mirror as 4.

Mageia 4, both 586 and x86_64, hasn't offered me an update to caja or mate-file-manager; x86_64 had somethings updated (e.g. libreoffice).

I used the function "Update your system" in drakconf and afterwards enabled new "Core release","Core updates" and "Core updates testing" which were available (in 586 it ends in distrib143, I believe).

You'll need this Renato
https://wiki.mageia.org/en/Enabling_the_Testing_media#Enable_them_the_easy_way

(In reply to Renato Dali from comment #28)
> I used the function "Update your system" in drakconf and afterwards enabled
> new "Core release","Core updates" and "Core updates testing"
Looks like the wrong way round!
DISable the normal 'updates' repos.
ENable their 'updates testing' equivalents.
Then update your system, selecting relevant pkgs only.
Then revert the repos testing -> normal.

CC: (none) => lewyssmith

Trying this MGA4 x64; before.

My system has many desktops, KDE & Mate included:
 mate-file-manager-1.6.3-1.1.mga4
 lib64caja-extension1-1.6.3-1.1.mga4
Switched to KDE and set the screen background differently to be identifiable. Tried a few things noted earlier, with slightly different results; which I note here before trying the update.
I could not find a menu entry for Caja.
Trying it from Konsole yielded:
 $ caja
** (caja:2501): WARNING **: Failed to get the current CK session: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files
The program 'caja' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 7 error_code 9 request_code 53 minor_code 0)
etc as in Comment 20.

Doing:
 $ caja --sync
** (caja:3865): WARNING **: Failed to get the current CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files
** (caja:3865): CRITICAL **: caja_file_unref: assertion 'CAJA_IS_FILE (file)' failed
(caja:3865): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x923f60' has no handler with id '2810'
etc etc many times; but yielded a FM window. When this was closed, the console prompt did *not* return - that needed Ctrl/C.

Re Firefox, I downloaded a file. Clicking the RH down-arrow, then carefully the little RH folder icon [clicking more loosely displayed the downloaded file], popped up a FM window which disappeared immediately; it *could* have been Caja.

I could not get mixed desktops with Alt/Tab.
About to try the update.

Lewis, try to keep the Konsole started "caja --sync" FM open and then use FF. This way Caja will open from FF without crashing immediately (at list it works for me).

BTW, you also didn't get an update. That behaviour does not happen with Attila's update on Cauldron. There Caja "exits when the last FM is closed".

Thanks, Lewis, for the tip about the Updates Testing. I thought repos were somehow additive in that a later version in Updates (or Updates Testing) would supersede Release. It seems it was one of my misunderstandings. More of that after the break...

Alas, it didn't work. (LOL... sorry, couldn't help)

Thanks, Claire, too, for the link.

I firstly thought "Aha! I'm missing the obvious!", which is failing to opt for updates in Core Updates Testing (see attached pic and urpmi.cfg excerpt, please).

Unfortunately I can't tick in that box. Clicking in it has no effect.

Frankly, this is not something I deal on a daily basis. This is a strong candidate for one of my weak points... :-|  I'd appreciate some hints about where I'm going wrong.

From the config file, it seems all those "repos" are actually the same and "Update your system" is just creating additional entries for the same ones. Is that normal?

Please bear with my ignorance about that subject... TIA!

Created attachment 6414 [details]
Lots of repos...

Created attachment 6415 [details]
urpmi.cfg excerpt with some "key" omitted

> I could not get mixed desktops with Alt/Tab.
> About to try the update.

Attila already made an update which fixed that, me thinks.

For that to happen you should have mate-file-manager-1.6.3-1.1.mga4.

If you got mate-file-manager-1.6.3-1.2.mga4 that problem IIRC is already fixed.

Continuing MGA4 x64 using KDE desktop, *after* the update:
 mate-file-manager-1.6.3-1.3.mga4
 lib64caja-extension1-1.6.3-1.3.mga4

Still cannot find a menu entry for Caja. From Konsole:
 $ caja
** (caja:7210): WARNING **: Failed to get the current CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files
(caja:7210): GLib-GObject-WARNING **: gsignal.c:2593: instance '0x1b63ef0' has no handler with id '2178'
 etc many times to
--- Hash table keys for warning below:
--> l2059
--> inode/directory
--> Lewis
--> lewis
(caja:7210): Eel-WARNING **: "unique eel_ref_str" hash table still has 4 elements at quit time (keys above)
(caja:7210): Eel-WARNING **: "caja-directory.c: directories" hash table still has 2 elements at quit time

which Comment 25 says is OK- but hardly encouraging. Importantly:
- It shows a correct Caja FM window. OK.
- When that is closed, the console prompt returns. OK.

Firefox: after downloading a file & clcking as per Comment 31, the FM window displayed:
- Is Dolphin (but as remarked previously, it takes ages the 1st time). OK.
- Stays visible. OK.
So I think this answers the bug as per Comment 23.

@Renato: Your recent comments are mostly to do with battling to test the update, wrestling with repositories Normal|Test. Invoking the Updates Testing repos in lieu of the normal Update ones is a bit fiddly; you have done your bit!

Ok, just tried disabling "Core release" and leaving "Core Updates Testing" only (firmly inside the realm of "shooting in every direction" now).

Nothing.

> @Renato: Your recent comments are mostly to do with battling to test the update, wrestling with repositories Normal|Test. Invoking the Updates Testing repos in lieu of the normal Update ones is a bit fiddly; you have done your bit!

Yep, you're right, some people simply don't know when to quit...

Well, I went to pbone.net, got the right package and installed by brute-force (heck!) and then ran caja in Konsole: it worked -- upon clicking on the [x] "close window" button, caja ends in the terminal window. This is the output on my M4 586 PC:

=====================================
[zz@localhost ~]$ caja
Initializing caja-open-terminal extension
Initializing caja-image-converter extension

--- Hash table keys for warning below:
--> l2050
--> zz
--> inode/directory
[zz@localhost ~]$
=====================================

No errors at all.

Testing then with FF, I noticed it opens Dolphin -- I counted (loudly) up to 38 while waiting for Dolphin to start. That must be some 30 seconds as we tend to say numbers faster than a clock. I think this is too much.

There was already a Dolphin window open (I used it to look for the rpm file and right-click to install it).

Repeating the FF thing -- i.e. asking it to open the download folder -- works fast enough on the second time (between 1 and 2 seconds). That's ok, me thinks.

Also, no sign whatsoever of the "switching desktop" bug.

Renato
Thanks for your perseverance.
> Well, I went to pbone.net, got the right package and installed by
> brute-force (heck!) and then ran caja in Konsole: it worked -- upon clicking
> on the [x] "close window" button, caja ends in the terminal window
> No errors at all.

> Testing then with FF, I noticed it opens Dolphin

> Also, no sign whatsoever of the "switching desktop" bug.

If you are using a 32-bit box (which it seems), would you please add to the Whiteboard at the top
 MGA4-32-OK
as you seem to have confirmed that the update resolves the specific problems it is supposed to. Save changes. That will clear this bug out.

The problem of a long wait in Firefox for the 1st Dolphin window display of the download folder might be worth another low-priority bug, but should not stop this one being closed. It would need researching whether it occurs only in this desktop mixture KDE with Caja also installed, or in other desktop/file manager mixtures.

> would you please add to the Whiteboard at the top

I'll be doing that in a moment...

Just for the record and to corroborate what you've already tested, I have a x86_64 machine and tested caja the same way.

It works even better: instead of closing when the FM window closes, it summons the FM window and closes immediately with no "extension" messages. Pretty much 100% figured, I'd say. Props to Attila.

Now, I had to restart the computer because FF still kept calling Caja after the update (I didn't even close Firefox). Maybe just ending the session would suffice.

After reboot, Dolphin was used by FF as expected -- the first time with an even longer wait (almost 40s -- I counted to 49) and thereafter with a small, normal 1~2 second delay.

Well done all and thanks Renato for your tests

Validating. Advisory uploaded.

Please push to 4 updates

Thanks

Keywords: (none) => validated_update
Whiteboard: MGA4-64-OK MGA4-32-OK => advisory MGA4-64-OK MGA4-32-OK
CC: (none) => sysadmin-bugs

It's been a pleasure and a learning experience.

If you'd like to get more involved Renato there are numerous teams available to join, QA team is just one of them, see https://wiki.mageia.org/en/Contributing

Every aspect of Mageia is community based which means it's only through people getting involved that Mageia gets made, so we always need more people!

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2015-0042.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Thanks, Claire.

I'll browse that link to see if any problem matches my skills 8-P -- and I think I will be staying here for some time to report that long start time of Dolphin in the first time.

Done, bug 15832 .