Bug 180 - "Open folder to a file" started Gwenview Dolphin instead
: "Open folder to a file" started Gwenview Dolphin instead
Product: Desktop Bugs
Classification: ROSA Desktop
Component: Main Packages
: Marathon
: i586 Linux
: Normal enhancement
: ---
Assigned To: Denis Koryavov
: ROSA Linux Bugs
Depends on:
  Show dependency treegraph
Reported: 2012-05-01 14:45 MSD by Postnikov Dmitry
Modified: 2012-06-29 12:19 MSD (History)
5 users (show)

See Also:
RPM Package:
Bad POT generating:
vladimir.potapov: qa_verified+
alex.burmashev: published+

att1 (121.95 KB, image/png)
2012-05-01 14:45 MSD, Postnikov Dmitry
Incorrect firefox file association (147.21 KB, image/png)
2012-06-18 17:37 MSD, Vladimir Potapov

Note You need to log in before you can comment on or make changes to this bug.
Description Postnikov Dmitry 2012-05-01 14:45:41 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.
See att.

В 260м образе. В Firefox в меню "Инструменты" - "Загрузки" хотим открыть папку с загруженным файлом. Кликаем правой кнопкой мыши по загруженному файлу и в меню выбираем "Открыть папку с файлом". У нас запускается Gwenview вместо Dilphin.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Comment 1 Postnikov Dmitry 2012-05-01 21:56:34 MSD
In 263th iso, does not run as Gvenviev Konqueror.

В 263м образе, запускается не GwenView, а Konqueror.
Comment 2 Denis Koryavov 2012-05-15 15:25:05 MSD
*** Bug 225 has been marked as a duplicate of this bug. ***
Comment 3 Alexander Burmashev 2012-05-25 12:47:00 MSD
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.
Comment 4 Denis Koryavov 2012-05-25 13:21:17 MSD
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.
Comment 5 Denis Silakov 2012-05-28 10:55:05 MSD
(In reply to comment #4)
> Here is the root of problem:
> cat /usr/share/applications/mimeinfo.cache | grep directory
> inode/directory=kde4-gwenview.desktop;kde4-kfmclient_dir.desktop;kde4-
> dolphin.desktop;
> https://bugzilla.mozilla.org/show_bug.cgi?id=727422

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.
Comment 6 Denis Silakov 2012-05-29 12:56:51 MSD
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...
Comment 7 rugyada 2012-05-29 16:56:14 MSD
they say:

create a file ~/.local/share/applications/defaults.list with this contents:
[Default Applications]

It works, but I have no idea if it may be stable or temporary workaround.
Comment 8 Alexander Burmashev 2012-05-29 17:03:16 MSD
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.
Comment 9 Denis Silakov 2012-05-30 12:46:47 MSD
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?
Comment 10 Denis Silakov 2012-05-30 19:38:02 MSD
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.
Comment 11 Denis Silakov 2012-05-30 19:51:48 MSD
... 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.
Comment 12 Alexander Burmashev 2012-06-06 17:03:30 MSD
I forgot to paste a link, here is the build list to the new firefox:
Comment 13 Denis Silakov 2012-06-13 13:15:02 MSD
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.
Comment 14 Alexander Burmashev 2012-06-13 13:17:52 MSD
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.

Comment 15 Vladimir Potapov 2012-06-18 17:37:30 MSD
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)
See attachment
Comment 16 Denis Silakov 2012-06-18 22:12:11 MSD
(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
> gwenview)
> (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)
Comment 17 Vladimir Potapov 2012-06-21 15:26:32 MSD
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?
Comment 18 Alexander Burmashev 2012-06-25 14:00:55 MSD
This package was published without proper QA check due to some  bug.