Open Bug 460891 Opened 16 years ago Updated 3 months ago

Wrong file name passed to helper app

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Platform:
All
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: rees, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

env NSPR_LOG_FILE=/tmp/log.txt NSPR_LOG_MODULES=HelperAppService:5 firefox
3.72 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092510 Ubuntu/8.04 (hardy) Firefox/3.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) 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.
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...
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.
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?
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?
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?
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:
http://mxr.mozilla.org/mozilla-central/source/toolkit/system/gnome/nsGnomeVFSService.cpp#107

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
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
Product: Core → Firefox
Version: 1.9.0 Branch → unspecified
Severity: normal → S3

This bug can be closed. It seems to have fixed itself some time in the last couple of decades.

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

Attachment

General

Creator:
Created:
Updated:
Size: