User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 If someone sends me an attachment with a filename that has spaces in it, say X Y Z.doc, that filename now gets saved in /tmp/plugtmp/X%20Y%20Z.doc, and apps that try to open it, of course, fail. This is like the 3rd time I've had to enter bug reports for linux versions that don't handle spaces properly. You really ought to create a small test suite to check things like this. It's a major annoyance. Reproducible: Always Steps to Reproduce: 1.Send yourself an email with a file that has spaces in it. It might matter whether this is done from Mozilla or not. 2.Read mail and open attachment. 3.Application opening attachment will fail. Look at file name in /tmp/plugtmp and you'll see that the %20s are in the name. Actual Results: The file was created in /tmp/plugtmp/ with erroneous %20s in there for each space. Expected Results: Saved the filename with spaces, not %20s. Then the app would not have problems opening it up.
By the way, this is a new bug in 1.4, and had been fixed in prior releases (probably fixed by 1.0 but I forget). I see you created this new /tmp/plugtmp directory so it's no surprise something else broke. Thanks!
this worksforme with linux trunk 20030725 and 1.4. the attachment was saved with the space, and the app launched fine. What type of file was it? Did Mozilla try to use an external app or a plugin to handle it?
Yes, as I stated, the app could not find the file because it wasn't saved with the spaces. So, the app was external (openOffice) and the file is saved in /tmp/plugtmp. It was not a plugin though; I specifically opened the attachment. This always worked with 1.3.
> So, the app was external (openOffice) and the file is saved in /tmp/plugtmp. It > was not a plugin though; I specifically opened the attachment. 1. plugger is perfectly happy to claim it handles openoffice/msoffice formats and pass them on to openoffice. 2. only plugins use /tmp/plugtmp 3. when you "open" an attachment that Mozilla thinks should be handled by a plugin, it will try to open the attachment in a browser window. what version of plugger do you have? I can open flash attachments with flash plugin and word docs with mozplugger/openoffice just fine (both with spaces). I have mozplugger 1.1.3 (1.3 is the latest) http://plugindoc.mozdev.org/linux.html#MozPlugger
I checked and plugger *is* handling these types of files. I've used plugger for so long I forgot. Anyway, I hope that helps you figure out the problem.
what version of plugger do you have?
plugger 4.0. Been using it for a long time, but there is no later version on the website. And again, this was all working until Moz 1.4.
Old version ... Still a problem with current versions like 1.7.5 or 1.8alpha6? If not, please resolve this bug as WFM.
Version: Trunk → 1.4 Branch
I don't know if this is related, but the browser also behaves (to my mind) oddly with attachments whose filenames have spaces (I haven't experimented with other "unusual" characters). HTTP response headers of Content-Type: application/octet-stream; content-disposition: attachment; filename=this is a file.txt make the browser prompt for what to do, but treat the file as having the name "this", rather than "this is a file.txt" I have found no way of escaping the spaces that don't literally save the file with the escaped characters instead of unescaping them. I haven't found a bug regarding that, but it seems related.
I should mention that it works fine with quotes around the filename content-disposition: attachment; filename="this is a file.txt" does do the right thing but since IE handles it "correctly" even without the quotes, there are situations where it's difficult to convince the powers that be to change their side to quote the value.
(In reply to comment #9) > I don't know if this is related, but the browser also behaves (to my mind) oddly > with attachments whose filenames have spaces (I haven't experimented with other > "unusual" characters). > HTTP response headers of > Content-Type: application/octet-stream; > content-disposition: attachment; filename=this is a file.txt > make the browser prompt for what to do, but treat the file as having the name > "this", rather than "this is a file.txt" > I have found no way of escaping the spaces that don't literally save the file > with the escaped characters instead of unescaping them. > I haven't found a bug regarding that, but it seems related. That is Bug 221028.
No further response, so I resolving this as WFM. Feel free to reopen if you can reproduce it with current trunk or 1.8 branch builds.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.