Bug 456026

Please provide more information about the ZIP you wanted to open.
I need to know the exact file extension _and_ which content-type the webserver was sending along for the file.
So if it was from a public webserver please let us know the URL and if not you might get some useful information when running firefox after exporting

export NSPR_LOG_MODULES=HelperAppService:5
and reproducing the issue and attach the console output.

Hi Wolf, 

Starting with  a fresh .Mozilla directory, there is initially no association for .zip files under Edit>Preferences>Applications.  Clicking on a zip file link creates the association with Wine (curious, since wine isn't associated with windows binaries in KDE).  

Here are a couple of URLS:

This is a 3d model;

http://www.sharecg.com/v/30702/Poser/Celebration-08,-day-3--Elfette-dress-for-mfd

This is a funny old graphic zipped:

http://hobbes.nmsu.edu/download/pub/windows/deadwin.zip

Attached is the requested log.  I loaded up Firefox, downloaded a Zip file, and attempted to open it from the Downloads Window. 

Created attachment 257856 [details]
Console output  from export NSPR_LOG_MODULES=HelperAppService:5 

I loaded up Firefox, downloaded a Zip file, and
attempted to open it from the Downloads Window.

On a related note, I just discovered PDF files are associated with the GIMP.  

Ok, let me explain a bit how this works in Firefox.
There is a list of helper applications in the preferences but these are just additional selections used to override the "automatic" mechanism to find the helper application to open some file.
Every desktop application provides a desktop file where it defines mime-types for all types the application is able to handle.
That includes PDF in Gimp and zip in Wine. Some SuSEconfig and mime-info magic chooses one default application which seems to fit best for certain types.
Since Firefox uses gnome-vfs to determine that stuff it actually prefers Gnome and Gtk applications as long as they are installed. If they are not installed gnome-vfs falls back (I guess) to the first hit for a certain mime-type which is probably not the best option.

Please check on your system the file /usr/share/applications/defaults.list and look up which desktop file it mentions for "application/zip" and "application/pdf"

Ah Ha!!

application/x-zip-compressed=wine.desktop

application/pdf=gimp.desktop

So this bug apparently belongs to whomever owns the generation of defaults.list- that would probably be the SUSEconfig folks?.

I deleted the above two lines from defaults.list and restarted Firefox and all works as it should.  

Should I file a new bug roport, or can this one be transfered to the appropriate group?

I'm not sure it is actually a bug but let's ask someone else.
You can modify that behaviour in /etc/gnome_defaults.conf FWIW.

The problem is apparent. The fix is not trivial.

As gnome-vfs is a GNOME application, it (AFAIK correctly) should prefer GNOME applications. In this case, no GNOME applications are present.

Even if GNOME ZIP archiver (file-roller) will be present, KDE user will not be satisfied with the result (using file-roller instead of Ark).

default.list cannot be changed on fly, as GNOME and KDE users can work in parallel on the same machine.


Fixes I can imagine:

1. Firefox will not use gnome-vfs with KDE.

2. I will write just another SuSEconfig script. It will do exactly the same like the current one, but it will prefer Qt/KDE applications instead of GTK/GNOME, read /etc/kde.defaults and save its result into /usr/share/applications/kde/defaults.list or so. Setting an environment variable (either some of GNOME* or XDG*) will force these gnome-vfs2 defaults under KDE.

Well, people using XFCE,... may complain in the same way, so probably rewritten of SuSEconfig scripts may create several versions of

3. Use defaults.list in the home directory generated by the KDE startup scripts.

4. Do the 2., but patch libraries accessing defaults.list. As defaults.list is used by GIO as well, the problem may raise over the time.

Note: XDG code already supports some types of prefixes, so it needs a deeper research before patching.

*** Bug 461362 has been marked as a duplicate of this bug. ***

I am not sure this bug has the right priority, as bug 461362 (the one marked a duplicate) is in my opinion a usability nightmare.

Every not so experienced user will have problems to view pdf-files running Firefox in KDE (4.1).

*** Bug 494345 has been marked as a duplicate of this bug. ***

Proposed solution:

- Ensure that all applications use XDG_PREFIX for defaults.list.

- Improve update-desktop-database to generate desktop specific defaults.list.

Discussion on the new configuration format:

http://lists.opensuse.org/opensuse-gnome/2009-07/msg00011.html

I did a first steps for the implementation of desktop specific defaults in glib->gtk+->gnome and desktop file utils:

Rewrite of MIME caching code, that will allow future extension:
https://bugzilla.gnome.org/show_bug.cgi?id=596192

Rewrite of update-desktop-database:
Here is a patch, that can generate more that one defaults.list.
http://pack.suse.cz/sbrabec/mime-types/

The full fix is very complex, so 11.2 will not have this fix yet.

I have finally finished the implementation:

desktop environment specific defaults.list: https://bugzilla.gnome.org/show_bug.cgi?id=630171

smart defaults per MIME heuristic: https://bugs.freedesktop.org/show_bug.cgi?id=30214

Testing OBS project:
https://build.opensuse.org/project/show?project=home%3Asbrabec%3Amime-defaults

Packages for testing:
http://download.opensuse.org/repositories/home:/sbrabec:/mime-defaults/openSUSE_11.3/
http://download.opensuse.org/repositories/home:/sbrabec:/mime-defaults/openSUSE_Factory/

Note: I did not yet verify that $DESKTOP_SESSION is set to "kde" in KDE session. If not, it is easy to do.http://download.opensuse.org/repositories/home:/sbrabec:/mime-defaults/openSUSE_Factory/

Created attachment 390777 [details]
gnome_defaults-to-defaults_conf

And here is a draft of the script that will migrate the old SUSE specific /etc/gnome_defaults.conf to the new /etc/xdg/defaults.conf.

With a bit of magic, the migration of customized admin defaults can result customized defaults.conf.

It is a good chance for configuration cleanup: not migrate desktop files of packages that are no more present in openSUSE or SLED.

The final script will probably look a bit different, as the defaults.conf contents is a subject of change and the final configuration may be done in multiple files.

The repository above was refreshed and now contains port for the latest Factory.

It does not contain following things:

- DESKTOP_SESSION variable is not set in all desktops. You have to add it manually to the session init scripts.

- gnome_defaults-to-defaults_conf (comment 16) is not there, so porting of customization of gnome_defaults.conf will not be imported.

This is an autogenerated message for OBS integration:
This bug (456026) was mentioned in
https://build.opensuse.org/request/show/88171 Factory / desktop-file-utils

Fixed in openSUSE 12.1

OK. Let's close this bug.

Anyway, the feature "Desktop Environment Specific Details in GIO/GTK+/GNOME" still waits for upstream review. Without it, SUSE GNOME team refuses to maintain such a large patch in downstream.

Please subscribe to the upstream bug if you are interested.