Wrong file name passed to helper app




File Handling
10 years ago
2 years ago


(Reporter: Jim Rees, Unassigned)


Firefox Tracking Flags

(Not tracked)




(1 attachment)



10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008092510 Ubuntu/8.04 (hardy) Firefox/3.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008092510 Ubuntu/8.04 (hardy) Firefox/3.0.3

pdf helper app fails because firefox is passing it the wrong file name. I have not checked to see whether other apps have the same problem. Possibly related to bug #444440.

Reproducible: Always

Steps to Reproduce:
1. Add a handler for pdf in ~/.mailcap. I use xpdf but I don't think this is critical.
application/pdf; xpdf %s

2. Go to Preferences -> Applications and set pdf to "always ask." This is to work around bug #444440.

3. Visit a pdf url with a blank in its name. Other escapable characters work too. I use http://pergatory.mit.edu/2.007/resources/FUNdaMENTALs%20Book%20pdf/FUNdaMENTALs%20Topic%207.PDF .
Actual Results:  
The helper will fail because firefox passes the wrong name to it. The file is actually stored as "/tmp/FUNdaMENTALs Topic 7-1.PDF" but the name passed to the helper app is "/tmp/FUNdaMENTALs%20Topic%207-1.PDF" In this example, xpdf prints "Error: Couldn't open file '/tmp/FUNdaMENTALs%20Topic%207-1.PDF'" and exits.

Expected Results:  
Helper app should be passed the correct file name "/tmp/FUNdaMENTALs Topic 7-1.PDF" and run normally.


10 years ago
Component: File Handling → File Handling
Product: Firefox → Core
Version: unspecified → 1.9.0 Branch
Hmm.  With mozilla.org nightlies from both now and early June (so before the Firefox 3 release) that URL works fine as far as I can tell (FC 9, but that shouldn't affect things).

Jim, would you be willing to test with a mozilla.org build on your system?  I'm not seeing anything obvious in the ubuntu diffs I can find that would cause this, but it's a first step, at least...

Comment 2

10 years ago
I'd be happy to, if you can give me a gentle nudge in the right direction to find an appropriate nightly build.

I wish I could tell you when this started happening. For some time I've noticed some pdfs wouldn't load and I've been using wget on them, but only recently discovered why.
A good thing to test first is probably http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0.3/linux-i686/en-US/firefox-3.0.3.tar.bz2

Grab that, put it in /tmp, untar, run

   /tmp/firefox/firefox -profile /tmp/test_profile 

so as not to interfere with your normal profile.  That's the mozilla.org version of what you're running.

Comment 4

10 years ago
I couldn't get the nightly to run. It just exits.
That's not a nightly.  That's a release...

Did you quit Firefox before running it, by any chance?

Comment 6

10 years ago
I got it to run by using my own profile, and it has the same problem. Could there be something in my profile or settings that is causing this?
Possibly...  Can you possibly do the equivalent of:

  env NSPR_LOG_FILE=/tmp/log.txt NSPR_LOG_MODULES=HelperAppService:5 firefox

and then point Firefox to the url in question (reproducing the bug), quit, and attach the resulting log file to this bug report?

Comment 8

10 years ago
Created attachment 344417 [details]
env NSPR_LOG_FILE=/tmp/log.txt NSPR_LOG_MODULES=HelperAppService:5 firefox

It's not my profile. The problem persists if I start with an empty profile.

I have attached the log.
That log looks about right (too bad the GNOME stuff doesn't log so much).

I wonder... what happens if your comment out or remove that line in your .mailcap?

Comment 10

10 years ago
No change. Also no change if I remove ~/gconf* .

I'm not running gnome, except for the gtk built in to firefox. Could that make a difference?
I'm not running gnome either.

But it sounds like you're getting a helper app from _somewhere_ here... and that whatever method launches that app screws up.

I bet dmose and sdwilsh would love to join in right about now!  And Mike, but he's already cced.
So, no gnome - does that mean we aren't using gnome vfs stuff?  If we are, the code in question is here:

Assuming we are going through LaunchDefaultWithFile

It might be interesting to also know what your mimetypes.rdf looks like.
Er... why are we doing the format_uri_from_input thing on the filepath there?  If gnome_vfs_mime_application_launch doesn't undo the escaping that presumably does (and I see nothing to indicate that it would), then that would cause this exact bug.
That was added by Mike in bug 421879, with biesi reviewing.  Perhaps they know.
It was not really added per se, merely ported. nsGnomeVFSMimeApp::Launch replaces nsGnomeVFSService::ShowURIForInput in nsMIMEInfoUnix::LaunchDefaultWithFile. nsGnomeVFSService::Launch was already doing the format_uri_from_input before calling gnome_url_show.
gnome_url_show ends up calling gnome_vfs_mime_application_launch_with_env without doing anything to the uri, so the end result is the same with nsGnomeVFSMimeApp::Launch

Comment 16

10 years ago
I've got a workaround and apparently no one else is seeing this, so I suggest this bug be closed.
Well... the thing is, if you see it then presumably other people with your setup also see it.  They just don't know enough to go file a bug.
QA Contact: file.handling → file-handling


2 years ago
Component: File Handling → File Handling
Product: Core → Firefox
Version: 1.9.0 Branch → unspecified
You need to log in before you can comment on or make changes to this bug.