ROSA Linux Bugzilla – Bug 180
"Open folder to a file" started Gwenview Dolphin instead
Last modified: 2012-06-29 12:19:05 MSD
Created attachment 99 [details]
Description of problem:
In 260th iso. In Firefox "Tools" - "Downloads" want to open a folder with the downloaded file. Click the right mouse button on the downloaded file in the menu select "Open folder to a file." We started Gvenviev Dolphin instead.
В 260м образе. В Firefox в меню "Инструменты" - "Загрузки" хотим открыть папку с загруженным файлом. Кликаем правой кнопкой мыши по загруженному файлу и в меню выбираем "Открыть папку с файлом". У нас запускается Gwenview вместо Dilphin.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
In 263th iso, does not run as Gvenviev Konqueror.
В 263м образе, запускается не GwenView, а Konqueror.
*** Bug 225 has been marked as a duplicate of this bug. ***
I am trying to reproduce it on latest EE + updated FF ( 10.0.4 ) and seems that everything is ok.
Dolphin is opened, not gwenview.
Here is the root of problem:
cat /usr/share/applications/mimeinfo.cache | grep directory
I think, for the first time we just can remove inode/directory setting from the gwenvew.desktop file.
(In reply to comment #4)
> Here is the root of problem:
> cat /usr/share/applications/mimeinfo.cache | grep directory
The reason is really described in that bug ^^^ (you can also take a look at https://bugzilla.mozilla.org/show_bug.cgi?id=568218 marked as a duplicate of 727422 - it describes exactly our case).
KDE stores associations in /usr/share/applications/mimeapps.list (global settings) and ~/.local/share/applications/mimeapps.list (per-user configuration, if user modifies something in KDE control Center). However, Firefox doesn't use these files, it only takes into account /usr/share/applications/mimeinfo.cache and ~/.local/share/applications/mimeinfo.cache.
I believe that this Firefox behavior is buggy; unfortunately, FF developers don't seem to have intention to fix it in the near future - they insist this comes from underlying Glib/GnomeVFS functions ("First g_app_info_get_default_for_type and then if GIO is not around gnome_vfs_mime_get_default_application"). I am not sure if it is easy to fix FF by ourselves, should dig this a little more.
We can patch KDE to update mimeinfo.cache along with mimeapps.list, but note that normally mimeinfo.cache is automatically generated using 'update-desktop-database' command, and is regenerated every time when e.g. some program installs *.desktop files to ~/.local/share/applications. So probably patching KDE is not the ultimate solution, since sooner or later mimeinfo.cache will be regenerated by update-desktop-database, and there is a great chance that our changes will be lost.
I've added a comment to FF bug 727422: something strange is going on with FF. Its developers insist that they just use the g_app_info_get_default_for_type() function, but a sample program demonstrates that this function takes mimeapps.list into account, while FF ignores this file somehow...
create a file ~/.local/share/applications/defaults.list with this contents:
It works, but I have no idea if it may be stable or temporary workaround.
Imho, this is a workaround, valid but not cool.
It's not good, when to fix something we have to mess with ALREADY predefined user settings or force something via user ( not system wide ) settings.
The suggested workaround is not cool, but maybe it makes sense to use it, if it works.
Some more investigations about the roots of the bug (also posted to upstream bugzilla):
It turns out that g_app_info_get_default_for_type is not reached in ROSA. When do_GetService() is called in nsGNOMERegistry routines, it doesn't detect giovfs and falls back to gnomevfs. So it is gnome_vfs_mime_* functions that do something wrong, but GnomeVFS is obsolete and I think nobody cares about fixing its bugs anymore.
So the question is - why FF doesn't detect giovfs? Is it FF bug or misconfiguration of the system?
Upstream has suggested a solution:
* manually pass '--enable-gio' to 'configure' when compiling firefox.
And this indeed solves the problem for me! FF uses file associations set by KDE if configured with this option.
... and maybe it makes sense to try to recompile thunderbird in the same fashion? It seems that it also doesn't pick up file associations set in KDE control center.
I forgot to paste a link, here is the build list to the new firefox:
The updated FF works fine for me, and I think we should rebuild thunderbird with the same configure option ('--enable-gio'), since it doesn't seem to pick up file associations from KDE Control Center, as well.
Firefox was rebuilt with --enable-gio to ensure that file associations are ok.
Opnening the folder with file from downloads firefox menu should now open dolphin, not gwenview.
Created attachment 283 [details]
Incorrect firefox file association
1) I can`t reproduce this bug both my i586 and x64 computers
2) I see incorrect file association on open png file in this bug (not gwenview)
(both before and after firefox update)
(In reply to comment #15)
> Created attachment 283 [details]
> Incorrect firefox file association
> 1) I can`t reproduce this bug both my i586 and x64 computers
> 2) I see incorrect file association on open png file in this bug (not
> (both before and after firefox update)
> See attachment
What program is set as a default viewer for PNG images in your KDE Control Center? If KolourPaint, then this is expected behavior. If you change this association to something else, then updated FF should pick up the new association and use the new program to open png images. Before update, there was a possibility that it will use the old program.
Though I am not sure ifthis is true for file types, the original bug was about clicking "Open Containing Folder" for any file in the Downloads window (which appear when you click Tools->Downloads)
1) My default KDE viewer is GwenView, not KolourPaint
2) I can't reproduce bug with "Open Containing Folder" on 2 computers and 3x installed ROSA systems.
I conclude that it is a floating bug that has not been eliminated completely in this assembly. Maybe after the installation must be cleaned any settings?
This package was published without proper QA check due to some bug.