I've updated our test server from Firefox 17 Vanilla (downloaded from mozilla.org and extracted to /opt/firefox) to CentOS's Firefox 24.2.0 package installed via "yum install firefox". It has worked so far but now with the new browser MIME type handling is sorta messed up. When downloading a file, any file, and selecting "open containing folder" from the context menu it doesn't open, instead I get the "Launch application" window where I can choose which application I want to assign to this particular action.
We use KDE3 in our environment and I could select /usr/bin/konqueror for this action but I don't see myself doing this for all our 2,000 users individually (and I also don't see the users' doing this themselves, instead they'll be calling IT support every time this window pops up). Since I'm about to roll out this update on our production server I need to find a way to either define MIME types globally or find the bug that causes Firefox 24 to mess things up. Needless to say Firefox 17 knows exactly what to do when I select "open containing folder" - it opens a new konqueror window just as it's supposed to.
Any ideas?
Firefox downloads: open containing folder doesn't work
Re: Firefox downloads: open containing folder doesn't work
I've never managed to get that working in KDE, it always opens the Gnome file manager for me even though I always use KDE! I'll look into it.
In the meantime, please could you do me a favour and go to Youtube, click and view any user's profile page, and let me know if there is high CPU usage (X as well as firefox)? You don't even need Flash or to watch a video.
I have been using vanilla Firefox too and find the RPM version (either 24 or 17) to perform rather poorly.I was initially impressed that they have a version of 24 that runs on CentOS 5, but soon changed my mind. If your users are using Firefox for critical tasks, I'd recommend you do a lot of testing to make sure it is really running OK.
In the meantime, please could you do me a favour and go to Youtube, click and view any user's profile page, and let me know if there is high CPU usage (X as well as firefox)? You don't even need Flash or to watch a video.
I have been using vanilla Firefox too and find the RPM version (either 24 or 17) to perform rather poorly.I was initially impressed that they have a version of 24 that runs on CentOS 5, but soon changed my mind. If your users are using Firefox for critical tasks, I'd recommend you do a lot of testing to make sure it is really running OK.
Re: Firefox downloads: open containing folder doesn't work
Unfortunately I can't check Youtube since we've blocked that in our firewall.
So far I haven't noticed any slowdowns ore and kind of bad performance compared to Firefox 17.
So far I haven't noticed any slowdowns ore and kind of bad performance compared to Firefox 17.
Re: Firefox downloads: open containing folder doesn't work
How did you change the "open containing folder" to start Konqueror in the first place? I still can't see how to this. In 17.0.11 it tries to launch Cervisia. I can't see any option in the application itself. I edited /usr/share/applications/mimeinfo.cache and managed to change the behaviour, but after that it launched the Gnome file manager instead, even though the only entry under inode/directory is now kfmclient!
How did you set up 17 to run /usr/bin/konqueror in the first place? An option within Firefox, or by editing something under /usr/share?
My downloads always go to the same tmp folder, and I've grown used to not using the open containing folder option. But it's still a minor annoyance that I can't configure it!
How did you set up 17 to run /usr/bin/konqueror in the first place? An option within Firefox, or by editing something under /usr/share?
My downloads always go to the same tmp folder, and I've grown used to not using the open containing folder option. But it's still a minor annoyance that I can't configure it!
Re: Firefox downloads: open containing folder doesn't work
That's the thing, I never had to change anything. It's always worked out of the box.
Now, with the RedHat-Version, I have to set it manually selecting /usr/bin/konqueror in the dialog that pops up the first time I select "open containing folder".
Now, with the RedHat-Version, I have to set it manually selecting /usr/bin/konqueror in the dialog that pops up the first time I select "open containing folder".
Re: Firefox downloads: open containing folder doesn't work
I've had a look at this while testing Firefox 24 again. You are right, it pops up a box asking for an application choice. It seems they have changed the way Firefox handles requests to open a folder, so that it uses the same mime type system as opening any other sort of file, rather than trying to use some sort of system default. The file containing these options is ~/.mozilla/firefox/<profile>/mimeTypes.rdf
From my point of view, that would be better, if only Firefox 24 ran properly for me. I could choose Konqueror and that would be it.
For someone administering a system with lots of users, it seems it's quite tricky. There are quite a few discussions about global mimeTypes.rdf files, but no solution. I've tried putting the file in various locations such as /etc/firefox and /usr/lib/firefox, but without luck. It seems there is no way to define a mimeTypes.rdf that would apply to all users. You could add your mimeTypes.rdf to the default user profile under /etc/skel, but that would only apply to new users created from then on, not retrospectively.
A hack would be to wrap /usr/bin/firefox in a script that checked the user's mimeTypes.rdf and inserted the file manager choice the first time they ran it. Messy, but could work.
From my point of view, that would be better, if only Firefox 24 ran properly for me. I could choose Konqueror and that would be it.
For someone administering a system with lots of users, it seems it's quite tricky. There are quite a few discussions about global mimeTypes.rdf files, but no solution. I've tried putting the file in various locations such as /etc/firefox and /usr/lib/firefox, but without luck. It seems there is no way to define a mimeTypes.rdf that would apply to all users. You could add your mimeTypes.rdf to the default user profile under /etc/skel, but that would only apply to new users created from then on, not retrospectively.
A hack would be to wrap /usr/bin/firefox in a script that checked the user's mimeTypes.rdf and inserted the file manager choice the first time they ran it. Messy, but could work.