[Bug 1551171] Re: /usr/share/applications/mimeinfo.cache is used for default applications in Firefox
Bug Watch Updater
1551171 at bugs.launchpad.net
Sat Jan 12 15:26:13 UTC 2019
Launchpad has imported 34 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=727422.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2012-02-15T14:17:20+00:00 dutchkind wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/0
------------------------------------------------------------------------
On 2012-02-15T20:51:55+00:00 Bugzilla-tf wrote:
*** Bug 727425 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/1
------------------------------------------------------------------------
On 2012-02-15T20:55:01+00:00 Bugzilla-tf wrote:
*** Bug 568218 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/2
------------------------------------------------------------------------
On 2012-02-15T21:53:50+00:00 Bzbarsky wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/3
------------------------------------------------------------------------
On 2012-02-16T07:55:53+00:00 dutchkind wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/4
------------------------------------------------------------------------
On 2012-02-16T09:24:45+00:00 ghomem wrote:
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 at localhost ~]$ xdg-mime query default application/pdf
AdobeReader.desktop
[gustavo at localhost ~]$ xdg-mime query default image/jpg
gwenview.desktop
[gustavo at localhost ~]
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/5
------------------------------------------------------------------------
On 2012-02-16T15:01:46+00:00 Bzbarsky wrote:
> 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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/6
------------------------------------------------------------------------
On 2012-02-16T17:14:07+00:00 dutchkind wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/7
------------------------------------------------------------------------
On 2012-02-16T17:19:05+00:00 Bzbarsky wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/8
------------------------------------------------------------------------
On 2012-02-16T23:49:23+00:00 ghomem wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/9
------------------------------------------------------------------------
On 2012-02-16T23:50:55+00:00 Chris Coulson wrote:
Bug 296443 should probably be WONTFIX after bug 713802 lands
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/10
------------------------------------------------------------------------
On 2012-02-16T23:59:31+00:00 ghomem wrote:
(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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/11
------------------------------------------------------------------------
On 2012-02-17T10:24:48+00:00 Chris Coulson wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/12
------------------------------------------------------------------------
On 2012-02-18T20:29:15+00:00 dutchkind wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/13
------------------------------------------------------------------------
On 2012-04-10T22:15:16+00:00 Mcastelluccio wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/14
------------------------------------------------------------------------
On 2012-04-26T06:27:00+00:00 Rion wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/15
------------------------------------------------------------------------
On 2012-05-29T08:50:25+00:00 urpm-tools wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/16
------------------------------------------------------------------------
On 2012-05-29T16:38:54+00:00 Bzbarsky wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/17
------------------------------------------------------------------------
On 2012-05-30T08:39:55+00:00 urpm-tools wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/18
------------------------------------------------------------------------
On 2012-05-30T14:17:53+00:00 Bzbarsky wrote:
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. :(
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/19
------------------------------------------------------------------------
On 2012-05-30T15:43:17+00:00 urpm-tools wrote:
Indeed, --enable-gio solves the problem in my case, thanks a lot!
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/20
------------------------------------------------------------------------
On 2012-05-30T19:55:31+00:00 Rion wrote:
with --enable-gio everything works as expected.
I hope it will become default soon.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/21
------------------------------------------------------------------------
On 2012-07-01T09:49:09+00:00 Jonathan Protzenko wrote:
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! :)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/22
------------------------------------------------------------------------
On 2013-01-14T01:19:19+00:00 Atrigent wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/23
------------------------------------------------------------------------
On 2014-02-27T05:11:00+00:00 Eevee-mozilla wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/24
------------------------------------------------------------------------
On 2014-03-02T19:13:04+00:00 ghomem wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/25
------------------------------------------------------------------------
On 2014-03-02T19:32:51+00:00 Eevee-mozilla wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/26
------------------------------------------------------------------------
On 2014-03-02T19:57:42+00:00 ghomem wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/27
------------------------------------------------------------------------
On 2014-03-02T21:09:56+00:00 Eevee-mozilla wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/28
------------------------------------------------------------------------
On 2014-03-02T23:21:02+00:00 ghomem wrote:
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 at 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 at 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;
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/29
------------------------------------------------------------------------
On 2014-06-08T09:40:40+00:00 PhobosK wrote:
(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)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/30
------------------------------------------------------------------------
On 2015-02-07T22:00:11+00:00 Fincer wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/31
------------------------------------------------------------------------
On 2015-02-20T12:35:02+00:00 flying sheep wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/32
------------------------------------------------------------------------
On 2016-03-04T11:08:30+00:00 Sergio Callegari wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1551171/comments/35
** Changed in: firefox
Status: Unknown => Confirmed
** Changed in: firefox
Importance: Unknown => Medium
** Bug watch added: Gentoo Bugzilla #321111
https://bugs.gentoo.org/show_bug.cgi?id=321111
** Bug watch added: GNOME Bug Tracker #678944
https://bugzilla.gnome.org/show_bug.cgi?id=678944
--
You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to Mozilla Firefox.
https://bugs.launchpad.net/bugs/1551171
Title:
/usr/share/applications/mimeinfo.cache is used for default
applications in Firefox
To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/1551171/+subscriptions
More information about the Ubuntu-mozillateam-bugs
mailing list