Problem with attachments whose filenames have spaces in them

RESOLVED WORKSFORME

Status

MailNews Core
Attachments
--
major
RESOLVED WORKSFORME
15 years ago
10 years ago

People

(Reporter: A.P. Russo, Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

1.4 Branch
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
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!

Comment 2

15 years ago
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?
(Reporter)

Comment 3

15 years ago
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.

Comment 4

15 years ago
> 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
(Reporter)

Comment 5

15 years ago
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.

Comment 6

15 years ago
what version of plugger do you have?
(Reporter)

Comment 7

15 years ago
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.
Product: MailNews → Core

Comment 8

14 years ago
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

Comment 9

13 years ago
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.

Comment 10

13 years ago
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.

Comment 11

13 years ago
(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.

Comment 12

13 years ago
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
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.