443153 - Firefox runs a wrong application (e.g. announces xpdf but runs evince)

Status: RESOLVED DUPLICATE of bug 444440

(Firefox :: File Handling, defect)

Description

[Vincent Lefevre]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008062908 Iceweasel/3.0 (Debian-3.0~rc2-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008062908 Iceweasel/3.0 (Debian-3.0~rc2-2)

When I click on a PDF file, Firefox says:

  You have chosen to open
    <file>.pdf
    which is a: Adobe Acrobat Document
    from: <URL>
  What should iceweasel do with this file?
    * Open with [xpdf (default)]
    o Save File
    [] Do this automatically...

and when I click on OK, evince is executed instead of xpdf!

Reproducible: Always

Steps to Reproduce:
1. Click on a PDF file.
2. Choose "Open with...".
3. Click on OK.
Actual Results:  
Firefox runs evince.

Expected Results:  
Firefox should run the announced application, here xpdf.

There may be security/privacy implications since an arbitrary program neither chosen by the user nor announced to the user is executed. Worse, Firefox takes $PATH into account, so that the program may not even be the expected one. For instance, if the user has created an evince script (e.g. that does a "rm -rf") in his bin directory, this script will be run without the user's consent.

This bug also occurs in safe mode (-safe-mode option).

Comment 1

[Jim Rees]

I can confirm this. It just started happening in FF3. FF2 was ok. It's very annoying.

I tried this workaround:
ln -s xpdf /usr/bin/evince

but it doesn't seem to work. The only way I can figure out to view pdf files now is to save them to a file and run xpdf separately.

Comment 2

[Jim Rees]

I have a workaround. I made a shell script called "evince" that runs the correct application. It strips the "file://" to get just a standard file name.

xpdf `echo $1 |sed "s'file://''"`

But this is obviously not a fix. I agree that the security implications make this a critical bug, and suggest that it be fixed asap.

Comment 3

[Valdis Kletnieks]

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1a1pre) Gecko/2008070704 Minefield/3.1a1pre ID:2008070704

I'm seeing this too, and am at a total loss as to where Firefox is even *finding* the name 'evince' to run - after adding overrides to both ~/.mailcap
and /etc/mailcap it *still* called evince.  I dread the thought of running strace and chasing down *every* *single open() call... 

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

It's coming from GNOME (GConf).

Comment 5

[Valdis Kletnieks]

OK, somewhere down in the morass of /etc/gconf/schemas it appears.  So much for /etc/mailcap and/or /etc/mime.types actually *mattering* like it did at one time, and still does for some *other* programs.

% find /etc/gconf/ -type f | xargs grep -l evince | wc
     71      71    3497
% find /etc/gconf/ -type f | xargs grep -l pdf | wc
     68      68    3358

And all of it in XML to boot.  That's just craziness. ;)

(And I'd not be surprised to find that such craziness is part of the root cause for this bug... Having more potential ways to specify a source of a data point increases the chances that the relative priorities get botched.  In the Elder Days, proper browsers looked in the app you had specified in the browser, then ~/.mailcap and ~/.mime-types, then the /etc versions, and then gave up in a nice deterministic manner.

OK, I'm done ranting now. :)

Comment 6

[Jim Rees]

This is absurd. I don't even run gnome. I use twm and xterm. Why should I be penalized just because gnome happens to be installed on my machine? What happens if gnome isn't even installed?

The string "evince" never appears in any file anywhere under my home directory, including ~/.mozilla.

"Craziness" is too mild a word.

Comment 7

[Mike Hommey [:glandium]]

Oops, I forgot this one was filed. I should have sent my patch here... anyways, now the patch is in the other bug, let's mark this one as duplicate.