When a PDF is clicked on in Epiphany, it downloads as expected but is then opened in GIMP rather than in Evince. Using gnome-open whatever.pdf, it does open in Evince.
I have used the approved method of changing the file association:
<mraudsepp> chainsaw: right click on a PDF, choose properties, go to the open with tab, check what you want to open PDFs
Is it possible that there is a separate MIME association table for Epiphany, that has gotten desynced from the other Gnome settings? Should I run a specific command to update it?
To confirm, since I made this MIME change, Epiphany has been restarted at least 20 times, and the system itself has been powered off overnight.
Portage 2.2_rc12 (default/linux/amd64/2008.0/developer, gcc-4.3.2, glibc-2.8_p20080602-r0, 2.6.27-04431-g04ab591-dirty x86_64)
System uname: Linux-2.6.27-04431-g04ab591-dirty-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T7300_@_2.00GHz-with-glibc2.2.5
Timestamp of tree: Unknown
dev-java/java-config: 1.3.7, 2.1.6-r1
dev-lang/python: 2.4.4-r6, 2.5.2-r8
sys-devel/autoconf: 2.13, 2.63
sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1
CFLAGS="-O2 -march=core2 -pipe"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-O2 -march=core2 -pipe"
FEATURES="collision-protect cvs digest distlocks multilib-strict parallel-fetch preserve-libs protect-owned sandbox sfperms sign strict unmerge-orphans userfetch userpriv usersandbox"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
USE="16bit 7zip S3TC X X509 a52 aac aalib ace acpi adns adplug alac alsa amd64 amr amrnb amrwb animgif aotuv aspell async asyncns audacious audiofile avahi bash-completion beagle berkdb binary-drivers binfilter bluetooth bonjour bzip2 cairo calendar cardbus cdda cddb cdparanoia cdr cdrom chardet chipcard chm cli consolekit cpio cracklib crypt css cups curl dbus device-mapper dhcp dirac disk-partition diskio divx djvu dmi dri drm dts dv dvd dvdr dvdread dvi ecc eds elf emboss enca encode epiphany erandom evo exif exiv2 expat fam fat fbcondecor ffmpeg fftw flac fortran ftp fuse g15 gconf gd gdbm gdl gdm gedit gif gimp glib glitz glut gmedia gnome gnome-keyring gnomecd gnutls gpg gs gsm gstreamer gtk gtkhtml gzip hal hddtemp hfs howl-compat hpn ical icons iconv id3 id3tag idle idn ieee1394 imagemagick imap imlib inkjar inotify ipod ipv6 irda isdnlog jabber java jbig jce john jpeg jpeg2k juju keyring lame laptop lcms ldap libburn libcaca libgcrypt libnotify libsamplerate libssh2 libwww lilo logrotate lzma lzo mad magic md5sum mdnsresponder-compat midi mikmod mime mjpeg mmap mmx mmxext mng modplug mono mp2 mp3 mp4 mpeg mplayer mudflap multilib musepack nano-syntax nautilus ncurses nemesi neon network-cron networkmanager nls nptl nptlonly nsplugin nuv nvidia ogg opengl openmp openssl otr ots pam pango pcmcia pcre pdf perl physfs pidgin plotutils png pnm policykit posix postscript ppds pppd pulseaudio python quicktime rar rdesktop readline reflection rss rtc samba scenarios scrobbler sdl session sftp shorten sid smartcard smp sms sndfile snmp soup sourceview sox speex spell spl sqlite srt srv sse sse2 ssl ssse3 startup-notification subtitles svg svgz sysfs syslog szip t1lib taglib tagwriting tcpd theora thesaurus threads tiff timidity tk tls totem trayicon truetype tta twolame unicode urandom usb vcd vnc vorbis vorbis-psy vte wav wavpack webkit wifi wma wmf wmp xcomposite xface xhtml xinerama xml xorg xpm xscreensaver xsettings xslt xulrunner xv xvid yv12 zeroconf zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="i810"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Can you please try with glib-2.18.3 (bumped just now)? Especially if using ~glib-2.18.2 right now. It has some MIME ordering fixes (though I'd expect lack of the fixes causing different problems than this)
(In reply to comment #2)
> Can you please try with glib-2.18.3 (bumped just now)?
Still not getting the .18.3 from portage:
[ebuild U ] dev-libs/glib-2.18.2 [2.18.1] USE="fam -debug -doc -hardened (-selinux) -xattr" 0 kB
Do I need to unmask that?
Just to confirm, I have completely obliterated my Epiphany profile in an attempt to fix this, and it had no effect. So it can not be the browser keeping stale settings.
(In reply to comment #3)
> (In reply to comment #2)
> > Can you please try with glib-2.18.3 (bumped just now)?
> Still not getting the .18.3 from portage:
> [ebuild U ] dev-libs/glib-2.18.2 [2.18.1] USE="fam -debug -doc -hardened
> (-selinux) -xattr" 0 kB
> Do I need to unmask that?
Sorry, I meant 2.18.2 - the upgrade you are being offered
Upgraded, cleared the profile. I'm sorry to report it still stubbornly opens PDFs in Gimp, not evince.
I think for me it stubbornly only offers to save or "Save as" the file
actually that must have been a bad MIME association from the server side. Now opening another PDF it opens it with... GIMP-2.6. This PDF support in gimp looks cool, but...
In short, this seems easily reproducable, and therefore can be investigated by anyone
Didn't have my association fixed yet, so nautilus was opening with gimp as well (apparently the system default then), but after fixing that, epiphany still opens with system default, not user default - so I think it just doesn't use the proper API (or the current API properly) and doesn't consider with user overrides properly
I just bumped 2.24.1 and this looks fixed, could you guys confirm ?
I still get GIMP open a PDF with 2.24.1-r10.
Hum actually I can also reproduce the other way around if I set gimp as my default pdf viewer, epiphany will insist on opening pdfs with evince.
Mart is probably spot on with his analysis of the problem.
Maybe this is related to:
epiphany-22.214.171.124-r10, glib-2.18.3 - same problem, Epiphany keeps opening pdf with GIMP instead of Evince, though GIMP is completely removed from "Open With" applications list.
I think this behaviour is related: Evolution opens pdf's in the Gimp when I double click on them, however when I right click on a pdf, I only get the one option "open in document viewer".
If I unistall the Gimp, pdf association works fine, until I reinstall the gimp again.
taking the pdf out of /usr/share/applications/gimp.desktop seems to make no difference.
it was finely fixed for me after editing:
(removing all entrys that had both pdf as type and gimp add app)
(removed application/pdf from)
I updated ~x86 on Friday (most of gnome 2.26, including evince) and still seeing the same behaviour. (pdf's open by default in the gimp, and not evince).
(In reply to comment #15)
> it was finely fixed for me after editing:
I just edited your "step 2)"
but I swapped the order instead of removing the gimp:
And now evolution opens pdf's in evince by default. I haven't tried epiphany.
It seems to me that a further problem with the file association
is that it is not possible to configure priorities in associations
without revdep-rebuild resetting them to default each time it is run.
For example: I want my default choice for opening any application/pdf
to be evince. But since I have also acroread installed each time
I run revdep-rebuild acroread is set to default. Very annoying.
Is there any fix available?
So, I've looked into this. update-desktop-database just walks the directories in dirent order (maybe alphabetical?) and prepends the desktop file onto the list for each mime type. This means that gimp ends up ahead of evince, since it's later in the alphabet. This will happen every time update-desktop-database happens, which should be any time any package installing a .desktop file is installed.
Obviously, we can fix this instance by changing the prepend to an append, but that's a complete hack for this particular instance, and may break other things.
Another possible solution is to optionally remove the claimed pdf support from gimp; that may not be a good solution either. Probably the .desktop format needs some indication that some app should be preferred to all others.
If update-desktop... is the culprit, then, maybe adding:
to /usr/share/applications/defaults.list would workaround the problem (that file has to start by "[Default Applications]"), the final /usr/share/applications/defaults.list should look like:
If this works for this and bug 289561 (in this case the line to add would be "inode/directory=nautilus-folder-handler.desktop"), I think that the way to go would be to add an echo for adding those line in affected ebuilds (nautilus and evince), since gnomies will likely want to get evince and nautilus as default; while /usr/share/applications/defaults.list could be owned by desktop-file-utils that would simply provide that file with "[Default Applications]" line
This issue also occurs with, e.g. text/plain, and possibly other mime types. For example if you go to http://code.djangoproject.com/ on any of their pages there is a "Plain Text" link at the bottom. When I click on the link Epiphany presents me with a dialog that asks explicitly if I want to open the page with "gedit". When I choose to open it with gedit, epiphany then precedes to open the file in OpenOffice Writer.
*** Bug 258559 has been marked as a duplicate of this bug. ***
I've got a similar problem for a while now - with nautilus. Opening files with the default application usually works perfectly on my system. Also the applications listed as alternatives in the context menu are as expected.
What I observed is that the problem is related to the URI with which the file is tried to be opened. When using a "normal" file location
(e.g. "/mnt/some/dir/a.pdf") nautilus opens the file correctly with Adobe Reader. When using a URI with a different protocol (e.g. "smb://host/some/dir/a.pdf") the default is suddenly GIMP instead of Adobe Reader. The context menu does not even list Adobe Reader as alternative. The strange thing is that the properties dialogue for the file lists the correct applications under the "Open with" tab, even the default is correctly Adobe Reader.
(I have a network storage which is mounted directly under "/mnt/", but can also be accessed by nautilus using "smb://...").
I just checked and verified that nautilus produces the same wrong behaviour with "sftp://...".
However, I don't have these provlems with epiphany or other applications (as far as I've checked).
Can someone reproduce this, maybe with other applications?
I just looked into this matter, as it keeps on bugging me.
update-desktop-database processes files in their 'natural order' (as listed by `ls -U`). This happens to put evince before gimp for me. As modern filesystems tend to store their directories as B+-Trees, this isn't even easy to work around.
So imho. update-desktop-database should put some order into this.
(In reply to comment #23)
I don't think this is a problem of update-desktop-database.
I tried opening the same PDF with the same application (nautilus) under the same environment (no changes to mime information/database/whatever).
The _only_ difference was the URI used to open the file (/normal/file/path vs. smb://server/path)! Using the former nautilus opens the PDF with acroread, using the latter would open it with GIMP.
Apparently there are different methods querying the mime database information depending on the protocol (as indicated by the used URI).
I have no idea how this is implemented in nautilus or gnome in general, so it would be nice if someone having knowledge in this area could look into this.
Anyone able to reproduce this "URI" dependent behaviour???
This is solved in 2.30