213927 - Problem with attachments whose filenames have spaces in them

Status: RESOLVED WORKSFORME

(MailNews Core :: Attachments, defect)

Description

[A.P. Russo]

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.

Comment 1

[A.P. Russo]

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

[Andrew Schultz]

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?

Comment 3

[A.P. Russo]

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

[Andrew Schultz]

> 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

Comment 5

[A.P. Russo]

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

[Andrew Schultz]

what version of plugger do you have?

Comment 7

[A.P. Russo]

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.

Comment 8

[OstGote!]

Old version ... Still a problem with current versions like 1.7.5 or 1.8alpha6?
If not, please resolve this bug as WFM.

Comment 9

[Philipp Hanes]

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

[Philipp Hanes]

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

[OstGote!]

(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

[OstGote!]

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.