/usr/share/applications/mimeinfo.cache is used for default applications in Firefox

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Build ID: 2012020800

Steps to reproduce:

With Firefox 10, and possibly before, default applications are selected by Firefox using /usr/share/applications/mimeinfo.cache, however, this list is a system generated list in random order and therefor does not reflect the user's preferences of which application should be used to open a file.

Actual results:

When I click on a pdf (for example), I want to have the option to open it in my default application, in my case in okular, and not in gimp. However, gimp is presented as the only choice because it happens to be the first in the row in /usr/share/applications/mimeinfo.cache. Selecting an other application is not very user friendly.

Expected results:

Instead of using the system wide cache Firefox should use $HOME/.local/share/applications/defaults.list or $HOME/.local/share/applications/mimeapps.list to honor the user's preferences, and if nothing is found there, then /usr/share/applications/defaults.list should be used instead of /usr/share/applications/mimeinfo.cache

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

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

We don't do anything with mimeinfo.cache directly. We just call into gnome-vfs using gnome_vfs_mime_get_default_application

Is that function doing the wrong thing on your machine for some reason?

I don't know, I don't use gnome, but some gnome libs are installed (Opensuse). But I use apparmor and when I blocked access to /usr/share/applications/mimeinfo.cache in the hope some other way was used, there was not even a default app shown, so I am quite sure it is used by firefox somehow. Besides, before upgrading from 9 to 10 I didn't have a problem with this behavior, it worked ok, although in thunderbird, which is of the same version all the time, it started in 8 or so that I suddenly had chromium as the only option to open url's which at the time I didn't trace back to this problem.

As for finding the default app, wouldn't that be xdg-mime query default ? And if there is a need to use mimeinfo.cache, why not have all apps listed there in the dropdown list so the user can easily select? Now a user has to know which executable he needs to open something, not always easy.

I agree with Dutch Kind that this should be handled on a desktop agnostic manner like xdg-mime.

I have to add that we had this problem since at least Firefox 3.6.x on KDE.

Possible solutions in order of preference:

1. make this work in a desktop agnostic manner (via xdg)
2. use the GNOME application order in the correct way (not via the cache file)

This first solution seems better because it would be up to the distribution to ensure that xdg* works well, whereas the second one may reflect the good or bad behaviour of GNOME.

Usage examples for xdg-mime query:

[gustavo@localhost ~]$ xdg-mime query default application/pdf
AdobeReader.desktop
[gustavo@localhost ~]$ xdg-mime query default image/jpg
gwenview.desktop
[gustavo@localhost ~]

> As for finding the default app, wouldn't that be xdg-mime query default

xdg-mime postdates the creation of this code. Bug 296443 covers using it.

Again, we're not actually using mimeinfo.cache ourselves. It's your GNOME configuration that's using it.

> Besides, before upgrading from 9 to 10 I didn't have a problem with this behavior

That's quite odd. I don't think this code changed from 9 to 10. Would you be willing to use nightly builds to find when the behavior changed for you?

> 2. use the GNOME application order in the correct way (not via the cache file)

Again, we are not doing anything with the cache file ourselves. We're just calling the official "get the app for a MIME type" GNOME APIs. First g_app_info_get_default_for_type and then if GIO is not around gnome_vfs_mime_get_default_application. You can see the code for yourself right here:

  http://mxr.mozilla.org/mozilla-central/source/toolkit/system/gnome/nsGnomeVFSService.cpp#204
  http://mxr.mozilla.org/mozilla-central/source/toolkit/system/gnome/nsGIOService.cpp#352
  http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/unix/nsGNOMERegistry.cpp#172

I'd like to focus on figuring out why there was a behavior change from 9 to 10 on Dutch Kind's machine here, though. _Something_ weird is going on there.

Maybe I first noticed the change by some update after which update-mime-database was called. A search on internet learned that the order of this cache file is randomly generated, although I understand it is not called directly. So I would say the problem has been there dormant and showed up after my cache was rebuilt. On thunderbird I noticed it before after a distro upgrade, possibly because chromium was now included in the opensuse build, which also resulted in a different cache. Just coincidence that I only discovered it now.

OK, in that case it just sounds like the real problem is we're asking GNOME for the information and your GNOME is effectively misconfigured.... Is this then effectively a duplicate of bug 296443?

It may be a GNOME problem but then it happens on at least two different distributions: Suse (cf Dutch Kind's report) and Mandriva (where I had the same problem).

Whether or not this is a duplicate of bug 296443 depends on what will be done regarding that one. If bug 296443 is to be fixed (ie, xdg is adopted) then I guess this one won't be much relevant.

Bug 296443 should probably be WONTFIX after bug 713802 lands

(In reply to Chris Coulson from comment #10)
> Bug 296443 should probably be WONTFIX after bug 713802 lands

But, is that good? Why tie the default associations to GNOME if we can have a desktop independent way of achieving that?

Using gio is a desktop independent way of doing that and isn't tied to GNOME. It's a hard dependency of gtk anyway. It implements everything we want, but it actually works (whereas xdg-mime and friends are pretty much unmaintained and are known for not being very reliable)

I'm still not sure what's causing your current problem though. This has worked fine in the past with gnomevfs

Ok, did some more investigations, when I copy the corresponding line containing for example pdf to $HOME/.local/share/applications/mimeapps.list then those settings are honored by firefox, when this is not found in this file then only the mimeinfo.cache is used. So, yes, firefox honors the user's settings if it is in that list.
Still, it would be nice to use something more desktop independent. Chromium uses xdg and that works fine for me, no extra configuring, it takes my user's kde's default apps without a problem. The problem with the gnome way is that when you don't have gnome installed you have to add all the required apps to this mimeapps.list manually because KDE only writes those apps to this list that are manually changed by the user's kde configuration when this is different from the system kde default. xdg has no problems in this respect.

GIO supports the shared mime specification, and so did GnomeVFS. If you run into problems with KDE, it should be a problem of KDE.
I've seen xdg-mime does some KDE specific operations.

Hi guys. I know nothing about your future GIO implementation but I hope it will support feature as in next example:

$ xdg-mime query default x-scheme-handler/xmpp
psi-plus.desktop

and about default applications. for some reason FF does not read neither ~/.local/share/applications/mimeapps.list nor /usr/share/applications/mimeinfo.cache on my system (gentoo gnome3). So I always choose applications manually for each new mime. moreover FF does not remember my previous choice and may suggest wrong app (looks like it just doesn't try to guess mime and chooses last selected app for any file).
xdg-open works fine though.
I checked XDG_* vars and they are correct

I love FF but chromium works much better in this regard.

It's interesting, g_app_info_get_default_for_type() by itself does take mimeapps.list into account. As an experiment, I have created ~/.local/share/applications/mimeapps.list with the following line:

  inode/directory=kde4-gwenview.desktop;

And used the following sample program:

    g_type_init ();
    GAppInfo *def;
    def = g_app_info_get_default_for_type ("inode/directory", TRUE);
    printf("EXEC: %s\n",g_app_info_get_executable(def));

It prints "gwenview". However, FF doesn't seem to take mimeapps.list into account and uses associations from mimeinfo.cache - e.g., when I click "Open containing folder" menu item for the downloaded file, the folder is opened using Dolphin (which is the default system-wide association), not Gwenview.

I do see g_app_info_get_default_for_type() is called in FF the code, so something strange is going on here, indeed. And this makes FF quite inconvenient for KDE users, since KDE stores file associations in mimeapps.list; as a result, FF doesn't use associations set in the KDE control Center.

Denis, would you be willing to just step through the relevant Firefox code on your system and see what g_app_info_get_default_for_type is returning, and whether it's even reached?

It turns out that g_app_info_get_default_for_type is not reached in my system, indeed. 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 probably there is no need to bother about these obsolete routines.

The question is - why FF doesn't detect giovfs? I am not a gio expert, maybe something is wrong with system environment/configuration, not with FF? I am using ROSA 2012 Marathon with FF 10.

You mean the do_GetService call returns null?

The most likely reason for that is that MOZ_ENABLE_GIO ends up not being defined. It looks like GIO is only enabled if the --enable-gio configure option is passed in when compiling.... See bug 713802 for why it's not defaulted on. But at least people who are compiling themselves can deal. :(

Indeed, --enable-gio solves the problem in my case, thanks a lot!

with --enable-gio everything works as expected.
I hope it will become default soon.

FWIW the problem seems to have gotten worse recently; GIMP 2.8 recently landed in Debian Testing, and somehow it got prioritized over Evince for PDF documents, which means every single PDF now opens with Gimp instead of Evince. I tried to override this in Preferences > Applications, but neither "PDF File" nor "Portable Document Format" entries had any effect. I wonder how that pane is supposed to work! :)

I've been hit by this recently, but for me the problem is that PDFs are being handled by Inkscape. My mimeinfo.cache file (the file that is being used by GIO and therefore Firefox) contains the following line:

application/pdf=inkscape.desktop;evince.desktop;zzz-gimp.desktop;

The "zzz-" thing is a hack added by my distribution - see http://bugs.gentoo.org/show_bug.cgi?id=321111. Oddly enough, the ordering here does not actually seem to be alphabetical, because inkscape is listed first. This is why Firefox (or GIO, more precisely) has been trying to open PDFs in Inkscape.

However, "xdg-mime query default application/pdf" IS alphabetical, because it does not use the mimeinfo.cache file. xdg-mime is actually a shell script, and it finds applications that support PDFs by grepping for the mime type in all of the .desktop files. The list of files passed to grep is alphabetical, so the list of files returned by grep is also alphabetical and starts with evince.desktop. Therefore, evince.desktop is what xdg-mime thinks is the default.

The core problem here is of course that there is no priority information in the .desktop files. The relevant freedesktop spec specifically forbids this - see http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html. The result is random priorities when there are no explicit settings.

No doubt this policy was created with good intentions, but the fact is that there are legitimate reasons to encode priorities in the .desktop files. Evince should clearly have higher priority than GIMP or Inkscape for PDFs. The "the first one that I see" policy used by GIO and xdg-mime when there is no explicit user preference is always going to suck.

Adding an explicit user preference worked around the problem for me. I don't use KDE or GNOME, so I don't have access to any of the fancy graphical configuration utilities, but the following command:

xdg-mime default evince.desktop application/pdf

...seems to have been effective.

I would personally argue against using the xdg-utils in Firefox, because they are shell scripts (seriously, wtf?) and because they don't seem to be inherently smarter aside from purely by chance returning the right answer in my case.

Having the same problem, KDE. Looks like this is GIO's fault, but also KDE's fault, but also I don't know what I'm talking about but here's what I've got.

Firefox opens PDFs in Inkscape, which is clearly insane. KDE opens them in Okular. Similarly, Firefox opens directories in Konqueror instead of Dolphin. xdg-mime gets both right:

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

But the first things in the mimeinfo.cache list are Firefox's (and GIO's) choices:

application/pdf=inkscape.desktop;gimp.desktop;kde4-okularApplication_pdf.desktop;kde4-active-documentviewer_pdf.desktop;
inode/directory=kde4-kfmclient_dir.desktop;kde4-cervisia.desktop;kde4-dolphin.desktop;kde4-filelight.desktop;kde4-gwenview.desktop;

Looks like xdg-mime detects if I'm running KDE and uses "ktraderclient", whatever KDE plumbing thing that is.

The difference appears to be that KDE respects an "InitialPreference" value within .desktop files -- the highest value wins. I can tell this is a KDE thing because the only files I have with such a setting are built-in KDE 4 apps. Okular is 8, Dolphin is 10. (kfmclient is also 10, so who knows what breaks the tie.) So, naturally, KDE applications will win over everything else unless otherwise specified.

GIO, of course, ignores all this nonsense entirely.

But, dearest CC list, there *is* a light at the end of the tunnel! You see, KDE *does* correctly write out user-preferred applications to ~/.local, but *only if you actually change them*. So if you want the builtin default of Okular to be your PDF reader, you can do something like this:

- Open System Settings > File Associations
- Find application/pdf
- Select Okular and move it down one space (!)
- Click Apply
- Select Okular and move it back to the top
- Click Apply again

If you don't actually make a change, KDE will cleverly assume nothing should be done, despite showing a dialog that clearly says "I'm doing things", progress bar and all.

Anyway, doing this for application/pdf and inode/directory has miraculously brought Firefox's opinion on those filetypes in line with mine, and all is well.

Not a Firefox bug, not really a GIO bug, arguably not even a KDE bug. No one caused the problem, yet the problem remains. Ah, computers. It's perhaps ironic that this was all caused by exactly the thing comment 23 proposes would fix it: priority in .desktop files.

Alex, nice contribution.

I was stated on comments 16-20 that GIO wasn't enabled on Firefox by default.

But on Ubuntu 12.04 we see after an ldd on libxul.so

libgio-2.0.so.0 => /usr/lib/i386-linux-gnu/libgio-2.0.so.0 (0xb3d55000)

and the problem still happens. For example, directories open with Gwenview instead of Dolphin because mimeinfo.cache contains this line:

inode/directory=kde4-gwenview.desktop;kde4-dolphin.desktop;kde4-kfmclient_dir.desktop;kde4-kdesvn.desktop;

So in the end is this a GIO problem or a Firefox problem?

Comments 16–20 are ancient; bug 713802, to enable GIO by default, was marked FIXED over a year ago.

tl;dr of comment 24: if you're on KDE, and Firefox isn't opening e.g. PDFs or directories with Dolphin or Okular, it's neither a Firefox nor a GIO problem. KDE supports a custom priority property in .desktop files, and built-in KDE apps have it set by default so they win out over everything else /if you haven't specified otherwise/. (Without this behavior, even KDE could start opening PDFs in Inkscape, because you never explicitly asked to use Okular. I'm not sure how GNOME et al. avoid a similar problem.) Meanwhile, GIO doesn't understand any of this because the property is non-standard.

If you manually edit your file associations, KDE *will* write out your choices in the standard way, and GIO will obey them.

Alex,

Firefox is still honoring mimeinfo.cache which is the title of this bug.

Even forgetting about any KDE specific support Firefox should honor

/usr/share/applications/defaults.list

so that a newly created user would have the system defined apps in line with his firefox settings. And a system administrador would know where to customize that on a system-wide manner.

You found a workaround that means doing things on a user-by-user basis - it is possible but brings manual work.

You say that Firefox currently uses GIO. If that is right then GIO has a bug because mimeinfo.cache should NOT be used as it lists applications in a random order and changes when packages are installed (therefore it can't be customized).

So the question is who to blame for mimeinfo.cache being used instead of defaults.list or xdg.

Thanks a lot, now I'm reading GIO source code. :)

I removed the application/pdf line from my local mimeapps.list and added a junk entry (VLC, certainly not listed in mimeinfo.cache) to the system-wide defaults.list, and now Firefox wants to open PDFs in VLC. So as far as I can tell, this is all working correctly; the only problem *I* had was that KDE doesn't write out its initial defaults in a standard way in the first place.

If you have a defaults.list and it's not working, all I can think is that you also have another file that's overriding it, since it's checked almost-last. The ordering is:
- [Default Applications] in mimeapps.list (GNOME-specific)
- [Added Associations] in mimeapps.list
- [Removed Associations] in mimeapps.list
- defaults.list (GNOME-specific)
- mimeinfo.cache
And each of these files is consulted in order, within each of the directories ~/.local/share/applications, /usr/share/applications, /usr/local/share/applications. Maybe you have some junk in one of those places?

You might want to just put your system-wide configuration in an [Added Associations] section in /usr/share/applications/mimeapps.list anyway, which I believe any DE will understand.

If you want to double-check what GIO thinks is going on without going through Firefox, a pretty easy way is to install the gobject bindings for Python (python-gobject on Ubuntu) and run:

    python -c 'import gio; print gio.app_info_get_all_for_type("application/pdf")'

One other (unlikely) possibility is that you have application/pdf configured as a subtype, and are being bitten by this bug, fixed after 12.04 was released: https://bugzilla.gnome.org/show_bug.cgi?id=678944. Check for a sub-class-of element in your /usr/share/mime/application/pdf.xml.

Anyway, given the above and my own experimentation, I'm reasonably sure that this is not a bug in Firefox. If anything it's a bug in freedesktop; http://www.freedesktop.org/wiki/Specifications/mime-actions-spec/ admits that there's no per-desktop way to specify defaults, and though they call the status quo desktop-specific, it's really toolkit-specific. Firefox is based on GTK+, so it uses the GNOME-specific API.

Alex,

You have a point here. After new tests on my system, based on Ubuntu 12.04 with KDE, where:

- there is a defaults.list
- there is a mimeinfo.cache
- there is NO mimeapps.list
- a new user has no specific settings on .local

it seems that defaults.list is currently honored and Firefox (GIO perhaps) falls back to mimeinfo.cache if the application defined on defaults.list does not exist on the system.

I had nautilus on defaults.list for inode/directory and Firefox was falling back to gwenview which is the first entry on mimeinfo.cache. I also tested changing the default application for PDF on defaults.list and it worked.

Can someone else confirm that defaults.list is now correctly honored?

---------------------------------------

Off topic: your python one liner does not behave has expected

user@1204-IGAC:~$ python -c 'import gio; print gio.app_info_get_all_for_type("application/pdf")'
[<gio.unix.DesktopAppInfo at 0xb71f68ec: Okular>, <gio.unix.DesktopAppInfo at 0xb71f6aa4: GIMP Image Editor>, <gio.unix.DesktopAppInfo at 0x9f35eb4: MuPDF>, <gio.unix.DesktopAppInfo at 0x9f35edc: Adobe Reader 9>, <gio.unix.DesktopAppInfo at 0x9f35f04: PDF Mod>]
user@1204-IGAC:~$ xdg-mime query default application/pdf
okularApplication_pdf.desktop

defaults.lst has:

application/pdf=kde4-okularApplication_pdf.desktop

mimeinfo.cache has:

application/pdf=gimp.desktop;mupdf.desktop;kde4-okularApplication_pdf.desktop;acroread.desktop;evince.desktop;pdfmod.desktop;

(In reply to Eevee (Alex Munroe) [:eevee] from comment #26)
> tl;dr of comment 24: if you're on KDE, and Firefox isn't opening e.g. PDFs
> or directories with Dolphin or Okular, it's neither a Firefox nor a GIO
> problem.

This is not exactly the case, especially considering opening directories with dolphin.

It turns out that FF (tested on 29.0.1 on Gentoo) when built with dbus support has a wrong way to do it.
It first calls (instead of checking if exists first and then calling) org.freedesktop.FileManager1 on the session bus and thus if nautilus is installed it is started as "/usr/bin/nautilus --no-default-window" and in this way FF doesn't honor the XDG at all.

So for now a workaround is either to delete the /usr/share/dbus-1/services/org.freedesktop.FileManager1.service or change its Exec to "dolphin" (if you are under KDE, though that may have implications 'cause dolphin doesn't register any org.freedesktop.FileManager1)

There is patched version of firefox available in AUR for KDE environment (Arch Linux users). It has better integration for KDE than the default and official firefox build. I compiled it with provided patches and, after all, file associations are finally as they should be in the first place - out-of-the-box, immediately. Running KDE 4.14.4.

https://aur.archlinux.org/packages/firefox-kde-opensuse/

I used to run Firefox from official Arch Package repos. File associations were just a mess at that time.

TL;DR: firefox should do exactly the same as `xdg-mime query default`

----

I don’t really care how GNOME does things, and I don’t care about GIO.

If

    $ xdg-mime query default application/pdf

returns

    okularApplication_pdf.desktop

Then I consider my system appropriately configured to open pdf files with Okular, and firefox not respecting this is a bug.

----

To help debug this:

The above query worked like displayed even while my ~/.local/share/applications/mimeapps.list and ~/.config/mimeapps.list contained no entry for application/pdf

Which probably means that something in the XDG spec other than mimeapps.list defines the order of default applications.

Firefox however opened PDFs with Inkscape.

Manually adding this line to one of the mimeapps.list files:

    application/pdf=okularApplication_pdf.desktop;

…made firefox open PDFs with Okular

A possible workaround is:

rm /usr/share/applications/mimeinfo.cache
touch /usr/share/applications/mimeinfo.cache
chmod a-w /usr/share/applications/mimeinfo.cache

This file together with the fact that desktops/distributions don't respect the freedesktop standards seems to cause more harm than good anyway.

Are you going to fix this one day? The bug exists now over a decade, the internet is full of help requests and no one seems to care …

https://www.google.de/search?hl=de&source=hp&q=firefox%20kde%20okular%20pdf%20system%20handler&aq=f&aqi=g10&aql=&oq=&cad=h

Just use xdg-mime to make it cross desktop compatible. Gnome is just one fucking desktop on Linux, but its still the only one that is supported by Firefox.

Bug 568218 points out the correct files to use for this: mimeapps.list → defaults.list, as defined by the mime actions spec https://specifications.freedesktop.org/mime-apps-spec/latest/

The “Default Applications” section says: https://specifications.freedesktop.org/mime-apps-spec/latest/ar01s03.html

> Indicating the default application for a given mimetype is done by writing into the group [Default Applications] in the file mimeapps.list.
> […]
> This example ensures that the application default1.desktop will be used for mimetype1, if it's installed, and otherwise default2.desktop if it's installed:
>
> [Default Applications]
> mimetype1=default1.desktop;default2.desktop

Hitting this same problem in Kubuntu 20.04.
My case is this. In /usr/share/applications/defaults.list I had this:
application/pdf=org.gnome.Evince.desktop;google-chrome.desktop

I guess the trailing ";google-chrome.desktop" was in some way added by installing Chrome.
Firefox says my default PDF application is Chrome, while all the other system components (Dolphin, xdg-mime, xdg-open) correctly say that my default is Okular.

After editing /usr/share/applications/defaults.list to remove the trailing ";google-chrome.desktop", now Firefox correctly knows my default application for PDFs is Okular. No need to restart Firefox, the change was immediate.

Strange enough, I don't have Evince installed, but many other file types are associated with Evince in that defaults.list file. I guess Evince is ignored because it is not installed. On the contrary, Chrome is installed and so it's honored by Firefox, but in this case it's skipping and ignoring my actual system settings for PDF file association.

So, there must be some problem here.

(In reply to Boris Zbarsky [:bzbarsky] from comment #6)

> … xdg-mime … Bug 296443 …

See also: bug 724461, bug 893799, bug 1304650, …

The severity field for this bug is relatively low, S3. However, the bug has 14 votes.
:Gijs, could you consider increasing the bug severity?

For more information, please visit [auto_nag documentation](https://wiki.mozilla.org/Release_Management/autonag#severity_underestimated.py).

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

It is still relevant; see for example https://bugzilla.mozilla.org/show_bug.cgi?id=1304650. https://wiki.debian.org/MIME has succinct info about the cache file, and https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/574342/comments/22 describes a workaround.

You could argue that this is a desktop environment bug, but from the user perspective "the right thing" happens when they open the downloaded item via their file browser of choice, and changing the default file association in their desktop environment settings tool doesn't influence Firefox behavior. Firefox is the outlier, and ought to be using the same handler application that xdg-mime would return.