Further testing shows the double Dolphin window occurred just in the Mageia 4 586 PC, not in the Cauldron one and not even in Mageia 4 x86_64.

The differences in the installations are:
- Cauldron uses a more recent Caja;
- Besides the normal difference between architectures, the name of one package is different (libcaja-extension1 versus lib64caja-extension1, or something like that).

I also reverted momentarily from Core Updates Testing to normal Core Updates.

Is it strictly related to having Caja installed while using Firefox in KDE?

For me on a clean KDE Cauldron Dolphin opens in ~2s when using the "Open folder" entry in the "Show all downloads" window.

> Is it strictly related to having Caja installed while using Firefox in KDE?

Changed all machines to Xfce to test and this is the situation, using the same steps above to trigger the bug:

Mageia 4 32-bit
---------------

Caja is opened twice after a long wait (circa 30s). Caja was previously set as favorite application in Xfce.

Changing back the default to Thunar, and testing it again, the same long wait happens, but Thunar opens only one instance.

Mageia 4 64-bit
---------------

There's a long wait, after which there's only one instance of... Dolphin! (the favorite file manager in Xfce configurations is Thunar).

The wait has been measured again at circa 27s, but on one single occasion start time was 15s (with Xfce).

This machine has LXDE, too... Dolphin is invoked with the same long initial wait.

Cauldron (still 5 RC3) 32-bit
--------

Thunar is opened after a long wait. Single window.

////////////////////////////

Thus it seems the problem is related to Mate or Caja, independent of the DE.

I have no idea why Dolphin is used in the X86_64 machine.

A more complete answer to your question would require the installation of the RC (which I intend to do sooner or later).

For the record, I too had excellent response time (1~2 seconds) with Dolphin when I just had KDE and Xfce installed -- and LXDE, too, considering the x86_64 computer.

The problems only arose because I wanted to test Mate to see if it's more nimble than Xfce on the PC with Mageia 4 32-bits. After installing it, I noticed bug 15604 .

Thanks for the additional information, I'll edit the summary to better reflect that the issue comes from interference with MATE/Caja.

Renato, is there a chance that you forget to make all these tests with an existed user account instead of a new user? There may be a corrupted configuration left from all other bugs you've experienced with Caja (15604, 15601, etc.)

Hi,Attila,

First of all, the bug I refer to in Comment #1 is bug 15604 and not 16504, as I've written.

> Renato, is there a chance that you forget to make all these tests with an existed user account instead of a new user?

Everything is possible...

I used existing users in all three cases above -- each one ran in a different computer. We're not yet using LDAP here at home; all machines have its own users -- actually, mostly one per machine -- except when I create a new user for testing or other nefarious activities.

The one where I first noticed the bug was the Mageia 586 one; as I was testing Cauldron, I tried to reproduce the bug, which surprisingly was not possible (Caja was crashing in M5 586).

According to what I've written in the aforementioned bug (15604), Caja initially crashed on my x86_64 Mageia 4 machine; your patch made things work again and Dophin was started by Firefox.

I just created two new users in the Mageia 4 x86_64 PC and confirmed that both in Xfce and in KDE, Firefox starts Dolphin to open the downloaded file folder. This computer is less "tweaked" than the Mageia 4 586 one.

First, it formerly ran Mageia 3 586 and when I decided to go for Mageia 4, I decided also to try that 64-bit. So, it's a pure installation, not an upgrade. BTW, 64-bit with 2GB RAM is not so great. Actually, I intend to install Mageia 5 32-bits on it next time.

Second, it's my wife & kid's computer, so I don't mess with it too much -- except to disable things -- if you have a 4-year old you'll understand why. On that machine, I also disabled the normal updates repo and enabled the "Core Updates Testing" one.

Perhaps I could do a Mageia 4.1 installation to test this as I was planning to install M5 RC this weekend.

Attila & Rémi, more tests:

I actually installed M4.1 586 over my Cauldron test machine (I had another which unfortunately went belly up). I expect to be able to post something on the weekend. For now, the results demonstrate that, without Mate, there's no delay whatsoever; there were other problems -- though somewhat minor. I will install Mate and do some additional tests.

On my M4.1 586 _production_ PC, I also verified the problem does not happen when:

1) directly clicking on a file manager icon (Thunar & Dolphin);
2) the FM is called by Chromium (clicking on little down arrow after download and selecting "Open/see in folder".

In both cases the right FM comes up quickly (well, if it takes 3 seconds it is somewhat annoying...)

I did not test on my x86_64/wife computer (yet).

It seems Firefox is doing something non-standard (is it using mime-types or that xdg thing?)

(sorry for the mess with names, I can't come to a conclusion about natural capitals use and Unix lowercase convention)

THE CONCLUSIONS:
===============

1. Installing Mate does something that makes one Firefox function take a long time (*) to be performed the first time; that function is opening a folder where a file was downloaded.

(*) 26~29 seconds, measured, depending on desktop -- KDE slower, LXDE faster.

2. Changing the default/favorite file manager application does not influence the problem (tested with Xfce).

3. Mate does not present such problem: Firefox opens the desired folder very fast also in the first time.

THE TEST:
========

For this test, I used a ~10-year old machine which still works reasonably well (IMHO). It's an AMD Sempron 2300+, 1.583GHz, 1.5GB RAM, enough disk, swap (not used) and Nvidia Geforce 6200 video with Nouveau driver. The motherboard is an A7V8X-X (BIOS from 2004).

This CPU has no SSE2 instructions (verbose discussion at bug 15594) and thus cannot run Chromium/Chrome and probably also not the new Opera, nor Midori, nor Qupzilla and neither Rekonq. IIRC Konqueror worked well. This might be a problem in the near future. And, no, I don't expect this computer to become unusable; if anything, I expect Libreoffice to become more lightweight or Calligra / Abiword to become more fit for my needs. Of course, hardware fails and everything comes to an end.

Mageia 4.1 was installed without KDE and Gnome. "Personalized" was chosen, KDE was unchecked and "Others (Window Maker, fvwm, etc." was selected. That includes, as later seen, IceWM.

No updating was performed during installation, which took some 40 minutes. After booting the newly installed system, all offered updates were allowed to be installed until the system was considered current.

Normal repos were selected: Core Updates and _not_ Core Updates Testing.

As a first test, an image was downloaded and FF used to open the d/l folder. Audacious was opened instead of a file manager. This was considered reasonable, since apparently there was no GUI file manager installed (neither pcmanfm, nor thunar, nor dolphin and also not caja). Perhaps the idea is using mc, which was available.

In sequence, task-kde-minimal 4.12.5 was installed following what was installed in my other 586 production PC, a more modern Pentium 1.60GHz (but with just 1GB RAM).

After some severe glitches (reported in bug 15462 with a workaround), it was noticed that Firefox could open a download folder with Dolphin (not Audacious!) in a reasonable time (circa 2s). No sign of the bug in discussion.

Then task-xfce-minimal 4.10 7.mga4 was installed and I logged into Xfce:
- Thunar opened quickly;
- Firefox opened Audacious (quickly...) even with Thunar as favorite FM.

Task-xfce-4.10 7.mga4 (not minimal!) was then installed. And nothing changed: FF would still call Audacious (though quickly).

At this point, LXDE was installed (task-lxde-3 8.mga4). From then on, Firefox would open the download folder with pcmanfm -- even in Xfce! And quite fast, BTW.

In LXDE, FF opened the d/l folder quickly with pcmanfm, as expected.

Finally, task-mate 1.6.0 8.1.mga4 was installed (9.2.mga4, like in the production PC, was not available). After some moments, though, an update to 9.2.mga4 was offered (and installed).

FF would now open pcmanfm in LXDE in approximately 26 seconds -- even without leaving LXDE, just after Mate installation.

Logging into Mate lead to a surprising result: FF could open the d/l folder without any wait with caja (actually 1+ second).

I then tried to change the favorite/default file manager to caja in Xfce. In that desktop environment, FF would take 29 seconds to open caja. It also opened it twice: one just opening the folder and another opening the same d/l folder, but with the recently downloaded file selected (I'm sure I didn't double-click BTW). It was previously noticed (in _one_ other computer) that selecting thunar as FM would lead to a single window, but selecting other FMs (like caja) caused two FM windows to open.

Good luck figuring this out. It might even be a FF problem... also, I wonder if a simple GUI file manager could be installed when KDE, Xfce, Gnome, Mate, LXDE aren't. Lightweight distributions favour ROXfiler, though I find it weird, and there's also SpaceFM -- used in antiX, seems OK but I don't know about its development status.

Thanks for any help... and for the superb work done to fix things until now.

The above please not to be understood as an endorsement of SpaceFM, which might be good, but I don't know very much. It was mentioned in the context of being lightweight.

I'm primarily a Dolphin and Konqueror user; these I find to be great.

I tested the bug to see whether it had something to do with disk hardware, seek times etc. by saving a file to a USB Flash/pen drive.

The results were the same: 28 seconds delay (measured) when opening the download folder in the Flash drive (from Firefox).

Please try to reproduce this with newly created user accounts, and please make the results a little less verbose. Please also include tests that are easier to reproduce and measure, like

xdg-mime query default inode/directory
xdg-mime query default x-directory/normal
LC_ALL=C gvfs-mime --query inode/directory # that is, if you have gvfs installed
xdg-open /home

CC: (none) => doktor5000

I usually have to ask the Pascal excuse: "Sorry for the long letter, frien, but I didn't have the time to make it shorter."

I tried to make it with less verbiage -- without much luck. Here it is:

I downloaded and burnt the Mageia 5 RC.

Installed it yesterday with all the defaults, except brazilian keyboard, no Nvidia driver, no updating during or after install and I checked that NTP was NOT activated.

New user created as part of installation.

KDE started -> display garbled -> desktop effects deactivated (ctrl shift F12, bug 15462 )

The asked results:

$ xdg-mime query default inode/directory
dolphin.desktop

$ xdg-mime query default x-directory/normal
dolphin.desktop

gvfs: unavailable

xdg-open /home

(opened with dolphin)

FF started, downloaded a pic, show downloaded files (ctrl_shift_Y)

Click on folder icon to the right

dolphin opens in ~2s

open mcc, install and remove programs (with only the RC DVD as repo)

Result: task-mate-minimal cannot be installed: conflict with mate-settings-daemon-gstreamer...)

open configure medias for update and installation

add internet medias

go to install and remove programs, choose all programs (not just GUI ones)

search task-mate-minimal

say ok to update rpmdrake when asked

then install task-mate-minimal

restart computer because of new glibc

with mate installed:

$ xdg-mime query default inode/directory
dolphin.desktop

$ xdg-mime query default x-directory/normal
dolphin.desktop

$ gvfs-mime --query inode/directory
Aplicativo padrão para "inode/directory": kde4-dolphin.desktop
Aplicativos registrados:
        kde4-kfmclient_dir.desktop
        kde4-gwenview.desktop
        kde4-dolphin.desktop
        caja-folder-handler.desktop
Aplicativos recomendados:
        kde4-kfmclient_dir.desktop
        kde4-gwenview.desktop
        kde4-dolphin.desktop
        caja-folder-handler.desktop
        
(tried that LC_ALL=C gvfs thing... works the same)

xdg-open /home

(opened with dolphin)

FF started, downloaded a pic, show downloaded files (ctrl_shift_Y)

Click on folder icon to the right

dolphin opens in ~26+s

Thanks.

Tested a little further today: by removing individual packages, I found Caja is the responsible for the delay. Installing it again makes the delay reappear.

Using top, I also saw that there's no increased usage of CPU or memory during the 26 second delay.

The present issue is similar to the situation described in bug 16124, which is about mixers (here the problem is with file managers).

On a pragmatic approach, like the one Jani Välimaa proposes in the aforementioned bug -- and which I consider valid, it would be better left to users to fix the resulting incompatibilities when software from another DE is installed.

In my comment #4 there, I further elaborate on why this might be a good idea for a community distribution like Mageia.

But I think we should consider the nature of the software being installed. Right I can envision three situations:

1. It's about a "commodity" utility like a mixer or even a terminal (like Konsole).

In this case, it really doesn't matter much which to use; if conflicts are simple to solve, like by the removal of a package, then the user could really take care of that.

2. In the other extreme, it's about some key application like the GIMP.

Here it's reasonable to assume many users will want that application working well and it's probable that the developer has made a great effort to make it work across different DEs. In this case, I think Mageia should make sure the application would work -- even if out of its original DE. Examples of that are GIMP, Inkscape, GCompris etc. when used in KDE (or other non-Gnome DE).

3. In-between cases.

Sometimes an application is more or less tied to a DE, yet it could be useful in other environments. Examples of that would be the excellent Kate editor in Gnome, or Konqueror (for some folder views), or Amarok (some consider it very complete) etc.

I put Caja in this latter category: it does not bring any special features that would make it useful in KDE (for instance, please correct me in case I'm mistaken).

But some people might feel more at ease with apps they already know -- or even the lack of features could be a desired trait.

Anyway, the 26 second delay happening during Firefox use is weird enough to warrant further investigation; I wonder if that problem could arise with other apps.

(In reply to Renato Dali from comment #15)
> Anyway, the 26 second delay happening during Firefox use is weird enough to
> warrant further investigation; I wonder if that problem could arise with
> other apps.

Then please investigate and attach a patch that fixes this, or at least report it upstream.

Whiteboard: MGA4TOO MGA5TOO => MGA5TOO

FWIW, reproduce the issue here too, firefox froze completely after trying to open a folder from the download manager. Maybe can be fixed in a similar way as decribed by Luc in https://bugs.mageia.org/show_bug.cgi?id=15601#c3
but that did not show an effect here.

Uninstalling caja immediately removes the timeout. Will have a look at caja.

Wow, just installed task-minimal-mate on my recently installed Mageia 5 and, to my surprise, it is as Doktor5000 says: Firefox seems to freeze for a moment; in reality, things are more complicated... it seems Kwin freezes. For instance, I can change areas (Ctrl-F2 etc.) instantly, I can see the Plasma desktop (Ctrl-F12) immediately, too, but window manager functions won't work. Focus stops following the mouse and I cannot select a terminal window to type in it; after changing and going back with Ctrl-F1, the Firefox window is not redrawn; I use an autohiding panel and it stops coming up... just 1 second before the file manager (dolphin) appears, everything returns like movement after a slo-mo scene. In fact, Firefox didn't freeze, we just cannot pass any click to it -- nor any key: anything that needs to be passed via kwin won't work.

Since I've seen this bug before, I patiently waited (which a normal user would never do) and verified the file manager took 2 minutes and 2 seconds to come up the first time! Things are getting worse... :-(

(To easily test that, after installing the aforementioned package:
1-kill FF with Ctrl-Alt-Esc;
2-restart FF and download a picture, for instance;
3-Click on the download arrow at right and the on the mini folder icon to open the location where the picture was downloaded)

I've found Mozilla's bug 727422 and reading comment #30 there came to a similar conclusion to the one in the answer in this post (by DrTobbe):
http://askubuntu.com/questions/530779/change-file-manager-used-by-firefox-on-lubuntu

I then edited the file
/usr/share/dbus-1/services/org.mate.freedesktop.FileManager1.service (note the extra mate) and replaced caja with dolphin.

This makes dolphin come up immediately, but kwin still freezes until a second dolphin window comes up. So, back to square 0.

Hmm, I believe the usual expression is "back to square 1"...

The best "solution" is to remove Caja, like Doktor500 mentions in comment #17. IMHO (and sorry to Mate users), dolphin is a better file manager anyway (and Konqueror is even better in some areas), at least in KDE.

Xfce or LXDE users might want Caja instead of Thunar or PCManFM(I don't know which one is better, frankly). But now this bug rears its ugly head in that situation...

Now for something completely different...

Some things I noticed while browsing internet posts (possibly not facts, but mere impressions):

1 - Mate follows the old model of the file manager controls the desktop while other environments separate desktop from the FM (like KDE)... this is because of two different meanings of desktop: a. the desktop area itself, which is a folder and thus the file manager should control it and b. an environment in which a desktop area is but a part of a greater whole (this is the KDE view, I think) -- from that difference, a lot of confusion arises... I don't know how important would it be for Mate developers to have their FM used in other DEs, thus I would suppose they have more pressing matters.

2 - Firefox developers are perfectly content in not being adapted to all DEs; to me, they seemed completely OK with the idea of solely developing for gtk-based Gnome, suggesting even that some Gnome things become standard throughout the Linux desktop landscape; given the present confusion, I cannot say they are to blame; instead, that shows the huge political struggles which are happening behind the stage, with different programs adopting different "common" configurations. All this means other DEs (KDE, Xfce, LXDE, Enlightenment etc.) will still have to adapt to Gnome configs in the years to come.

While I seem to be complaining about FF, they're the good guys, other browsers have yet more stricter requirements than them.

Just a clarification:

When I mention that the best solution is to remove Caja (comment #19 above), I mean it only in the context of the current bug (i.e. in case some wants to use another DE).

By no means I would suggest removing Caja or Mate from Mageia. It is not only a very respected DE which many people love, even a non-user like me can see the obviously faster response times Mate offers.

As it happens, I like to be able to log out and choose another DE to log in -- and I was having trouble to do that after installing Caja.

My preferences aside, it's worth noting that many distributions bypass the problem -- either by offering fewer or even a single DE option or, as Mint does, by offering different ISO images for the supported DEs.

Assigning to all packagers collectively, mainly because I don't know who to assign. Please reassign to a more appropriate maintainer and set the RPM field to an appropriate value if can be done.

Assignee: bugsquad => pkg-bugs

It seems no one have seen this for long

Status: NEW => RESOLVED
CC: (none) => fri
Resolution: (none) => OLD