This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 496237 - mimeinfo.cache lists applications for PDF files in an inappropriate order (gimp before evince)
mimeinfo.cache lists applications for PDF files in an inappropriate order (gi...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: shared-mime-info (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-17 09:50 EDT by Garrett Mitchener
Modified: 2010-03-06 20:04 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-15 04:33:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Garrett Mitchener 2009-04-17 09:50:47 EDT
Description of problem:

The symptom is that in firefox and thunderbird, when you ask to open a PDF file, it tries to use GIMP to open it rather than evince or okular or acroread.  And there are various work-arounds, but in particular, using nautilus and the file properties box to say you want to open PDF files in evince for example doesn't change things in firefox and thunderbird.

The problem seems to be caused by the fact that /usr/share/applications/mimeinfo.cache contains this line

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

which puts GIMP ahead of all the normal PDF viewers.  This problem appeared recently, and I suppose it might have been caused by a recent GIMP update, but I haven't had time to look into that.

If edit mimeinfo.cache and move gimp.desktop; to the end of that line, firefox and thunderbird automatically pick one of the other viewers for PDF files and all is well.  But as soon as you install a package update that calls update-desktop-database, the fix is lost and you have to do it again.

I'm filing this here because there doesn't seem to be a nice mechanism within the .desktop architecture for specifying how the mimeinfo.cache file and programs that use it should prioritize all the applications that claim to handle PDF files.
Comment 1 Ruben Vermeersch 2009-04-22 07:59:33 EDT
Happens in rawhide too.
Comment 2 George Karabin 2009-05-01 10:24:21 EDT
I see the problem in Fedora 9 as well.
Comment 3 Paul Johnson 2009-05-06 00:43:06 EDT
Me too!  I have just had this problem on RedHat 5.3. 

I think "update-desktop-database" should be removed and/or RPM post install scripts should not be allowed to call update-desktop-database until these problems are cleared up.  We desperately need documentation on update-desktop-database and we need some method to prioritize programs so that the ones we actually want are at the front of the list in /usr/share/applications/mimeinfo.cache.

I spent the day tracking down the problem in our computer lab.  We updated kdegraphics and bam! all of the users went crazy when they tried to view pdf files.  A program called kghostview, which doesn't appear to be able to display most of the pdf files we use, was being called.  It is quite baffling because /usr/share/applications/defaults.list does have evince.  It appears lots of programs ignore defaults.list, and they just read the mimeinfo.cache file.  Even when configurations use xdg-open as the pdf viewer, readers were not getting evince.  

Did you notice that update-desktop-database has been removed from the README file that is provided with the xdg file utils?
Comment 4 Bug Zapper 2009-11-18 06:45:00 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Stijn Hoop 2009-12-04 05:33:52 EST
Seeing this on Fedora 12 as well:

[stijn@pclin250] </usr/share/applications> grep xpdf mimeinfo.cache
application/pdf=fedora-xpdf.desktop;kde4-okularApplication_pdf.desktop;gimp.desktop;evince.desktop;

The version of this bug needs to be updated to 12, or possibly rawhide.
Comment 6 Bug Zapper 2009-12-18 04:16:14 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 7 Stijn Hoop 2010-01-06 03:39:40 EST
*ping*

This is still the case on Fedora 12 as I submitted in comment #5

Please reopen.
Comment 8 Ray Strode [halfline] 2010-01-06 09:43:44 EST
the lists in mimeinfo.cache are in random order.  If it's choosing one from the list then that means we need a defaults.list update.
Comment 9 Stijn Hoop 2010-01-06 10:54:46 EST
Right, now I feel silly. Thank you for reopening this but...

I know that at the time I double checked this (comment #5) it was the case that for me all PDF files opened using xpdf instead of evince. I also know that I did not ever select xpdf as the default PDF opener. I remember checking the configuration in ~/.local by hand to verify this. Hence why I provided the output I did.

After making comment #5 I used the nautilus interface to select Evince as my default PDF viewer in order to work around what I thought was this bug.

However, now that I'm attempting to reproduce this on an up to date Fedora 12 I cannot get this to happen anymore. I deleted my ~/.local/share/applications/mimeinfo.cache etc, and I got evince by default. I also made a new test user without any settings and still got evince by default.

So I'm very sorry for the bug spam but I don't see this anymore as I did previously... therefore I support this bug being closed again :(
Comment 10 Ray Strode [halfline] 2010-01-06 11:02:34 EST
just to confirm, looking in defaults.list I see:

application/pdf=evince.desktop

reclosing.
Comment 11 Paul Johnson 2010-01-06 16:21:39 EST
Well, I have this in defaults.list, 
application/pdf=AdobeReader.desktop

but these systems all still use evince to try to open pdfs.  Since evince can't print most of the pdf files we open (a different bug), I'd rather not have it pop up at all.  The only explanation I can figure out for this is that mimecache.info has this:

application/pdf=evince.desktop;AdobeReader.desktop;

And even when I go in and change that by hand so that it does not use evince first, the update cache program runs and obliterates the change. 

I'm poster of #3 in this thread, and I still think there's a problem
Comment 12 Ray Strode [halfline] 2010-01-07 09:46:52 EST
how do you have application/pdf=AdobeReader.desktop in defaults.list ?  defaults.list is a static file shipped with the distribution in the shared-mime-info package.

If you want to change the default for pdfs, right click on a pdf file and choose properties, then go to the "Open With" tab.
Comment 13 Paul Johnson 2010-01-08 02:10:37 EST
I need to make a change for all users, not just one user.  How else except by editing defaults.list and futzing about with mimecache.info???  We find that Evince does not print most PDFs that our users find. That's a known problem that is being worked on in the evince/cairo teams, but until then I don't want to hear the constant complaints from lab users who say "the printer is not working" (when in fact they've just hit the weird behavior of Evince).
Comment 14 Ray Strode [halfline] 2010-01-08 10:04:33 EST
Unfortunately, I don't have a good answer for you. CCing Alex, because he might.  (it's been a really long time since I've looked at mime handling stuff and some of the details have changed since I've looked).

From briefly reading the code, it looks like you can make the changes for one user, and then:

mkdir -p /usr/local/share/applications
mv ~/.local/share/applications/mimeapps.list /usr/local/share/applications

That's obviously not a great solution though.  What we really need is the ability to edit

/etc/xdg/applications/default.list

and have that work.  It doesn't look like the code works that way though.
Comment 15 Alexander Larsson 2010-01-14 05:07:05 EST
I think there is some confusion here as to where the bug is:

miminfo.cache is not a priority system, it is just a simple cache that lists (in random order) which desktop files list that they support each mimetype, so that you can avoid reading all the desktop files to get this info.

For each user there is a priority list of what applications should handle each type. This is standardized to some level between kde and gnome. This information is stored in ~/.local/share/applications/mimeapps.list (can be changed with $XDG_DATA_DIRS).

An example file here may look like:
-----------------------------
[Added Associations]
text/plain=gnu-emacs.desktop;gedit.desktop;

[Removed Associations]
text/plain=gvim.desktop;gnome-file-roller.desktop;
-----------------------------

The added associations are added to the list of apps that handle the mime type, and additionally the list is sorted in priority order for picking the default app. The removed associations stuff is so that you can hide system installed apps.

If there is no match in this for the mimetype, then the system default is picked. The system default currently varies between desktops. In gnome we first look at the default.list file and follow its ordering, if there is nothing specified there we pick the first in the (randomly ordered) mimeinfo.cache list. Kde has another system with some form of priority stored in the desktop files.

There has been discussions on having a common system default too, but its hard to come up with a good system there because the exact priorities to user are obviously different on the different desktops, so there has been no progress on this.

Going back to this bug, it seems that something is not following this system but instead only looking at mimeinfo.cache. We ship a default.list file that lists evince as handling pdf files, and kde has its priorities that probably picks okular. And both the gnome code (in gio) and the kde code should be following the standard for user-specific preferences. So it seems to be some application implementing this by itself, wrongly.

So, what applications do you see this behaviour in? nautilus? dolphin? firefox?
Comment 16 Garrett Mitchener 2010-01-14 09:16:17 EST
Thanks so much for clarifying this.

I only saw this problem in firefox and thunderbird, and it seems to have gone away now that I've upgraded to fedora 12.  Is there documentation posted somewhere for developers on how to appropriately interact with the user's preferred applications in gnome and kde and xfce etc?  I don't do much development, but when problems like this show up, that documentation would help me track down the problem and maybe file better bug reports.  (In hindsight, this was probably a mozilla bug.)
Comment 17 Alexander Larsson 2010-01-15 04:33:31 EST
Generally these things are discussed on the xdg@freedesktop.org list and then written down as freedesktop standards. However, the mimeapps.list stuff hasn't actually been written down yet, due to lameness on our (the participants of the discussion) part.

Marking this as closed then.

Note You need to log in before you can comment on or make changes to this bug.