Closed Bug 94705 Opened 23 years ago Closed 23 years ago

attaching a rtf doc

Categories

(MailNews Core :: MIME, defect)

Product:
MailNews Core
Component:
MIME
Platform:
All
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 95504

People

(Reporter: markmul, Assigned: bugzilla)

References

Details

When attaching a rtf document the formatting of the document is displayed in the
body of the message
Please always include build ID in bug-reports.
Mozilla's native "internal" rdf support (broken) was causing some havoc because
rtf files were showed inline, the the parser was incomplete. (Bug 40058)
The rtf support was later removed. (Bug 78458)
Bug 90688 was partly about the same issue as this bug, and was marked dup og bug
52441, now fixed. 

Yet bug 94816 is filed with build ID 2001080110: 
"RTF attachments show inline as code" (Win98)

Seems there are still MIME as well as parser issues left. Was the rtf support
really removed?

Resolving as new, based on the dup.
CC bzbarsky.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 94816 has been marked as a duplicate of this bug. ***
From the dup:

Reproducible: Always
Steps to Reproduce:
1.  Create RTF document and save to disk.
2.  Using one identity, mail yourself a message and attach the RTF document.  I
used POP3, but I don't know if that's important.
3.  Retrieve the message from your server.
More quoting:

"Document will not open as a separate document using the application registered
in the OS [...] using the right-click/Open method that works for other
attachment formats."
When you mail the rtf attachment, what mime type is it sent as?  This should be
visible in the source of the mail....
Comments from reporter:

I don't think I can answer your question, because the operation was
done with Mozilla's Mail&News modules, which I've since uninstalled.
I can only tell you that I created the rtf documents in Lotus'
WordPro, saved as MS' Rich Text Format.  Then created a mail message
in Mozilla's mail module, and attached the document through the mail
interface.  I don't recall changing any MIME-related option when I
customized the mail program after installation.  I don't know if this
helps, but I'm not sure I can add any more info.

------------------------------

I would bet that Mozilla is sending the RTF as text/plain or something silly
like that.....
Back home i tested this, mailing myself an rtf attachment.
And it displays inline all right - a complete mess.
However: I *can* save it from the attachment "pane" in mailnews.
This is from source in sent folder:

Content-Type: text/plain;
 name="mindrover.rtf"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="mindrover.rtf"


And as observed above: "Open" fails to prompt for anything. Moz thinks it
handles the situation just fine as it is, but content isn't very readable
between all the formatting code.
OS: Linux → All
Hardware: PC → All
> I would bet that Mozilla is sending the RTF as text/plain or something silly
> like that.....

> Content-Type: text/plain;
> name="mindrover.rtf"

There we are.  We're sending the rtf as the wrong mime type.  No reason not to
display text/plain inline.

Over to MIME.  If we sent it as something we don't know how to display, we would
not display it inline....
R.K.Aa, are you doing this on Linux or on Windows?  Also, is there an entry for
rtf in whatever mime.types files your prefs point to?  That is, is this a
problem with not trying to get the correct MIME type, or a problem with not
getting it because the setup is wrong?
Assignee: sspitzer → ducarroz
Component: Mail Window Front End → MIME
I use Linux and have not set mozilla up for anything regarding rtf - it invents
this all on it's own.
I don't have a mimetype defined for Netscape 4.77 either for that matter;
The entry in prefs/navigator/applications there does list Rich Text Format, but
it's handled by "unknown, prompt user".

> No reason not to display text/plain inline.

Way i see it there are plenty of reasons to display text/plain inline, but no
reason to assume rtf is text/plain. Then again - i'm a merry amateur.


I have not pointed Mozilla to anything regarding mimetypes - i have no idea how
to point it manually to my .mailcap or .mime.types, and i have no idea what
defaults Mozilla would attempt to pull these days.

There single reference i find in common linux system files are a reference to
rtf in /etc/mime.types where it's listed as
application/rtf
		rtf
text/rtf
		rtf

Those  haven't carried over to my homedir's .mime.types however.Should i test
removing the entry in global mime.types ?

(I believe the mimetype in gnome setup is utterly unused by mozilla - luckily -
but just in case: it's set to application/rtf with ApplixWare as default
application.)
> no reason to assume rtf is text/plain

Sure there is.  If we have no actual info on the type, we should run it through
the unknown content decoder, and that defaults to text/plain...

> i have no idea what defaults Mozilla would attempt to pull these days

I would not pull any.

Try this:

user_pref("helpers.global_mailcap_file", "/etc/mailcap");
user_pref("helpers.global_mime_types_file", "/etc/mime.types");
user_pref("helpers.private_mailcap_file", "$HOME/.mailcap");
user_pref("helpers.private_mime_types_file", "$HOME/.mime.types");

Replacing $HOME with the actual path to your homedir.  Then try sending this
mail again.  

> Should i test removing the entry in global mime.types ?

If you do that then there is _no_ way we can do anything correctly with rtf
files.  :)  Don't delete it, please.

> I believe the mimetype in gnome setup is utterly unused by mozilla - luckily

Why luckily?  And where does that information live?  Arguably, we should use it....




How smart is the unknown content decoder? Does .xbm files also come through in
plain text in mailnews on linux?

("luckily" about gnome's mime types because i've had nothing but trouble with
them. In cases impossible to modify through the given GUI based interface.)
> How smart is the unknown content decoder? Does .xbm files also come through in
> plain text in mailnews on linux?

If xbm contains 8-bit chars, then no.  But xpm may come through as text/plain....

Realistically, the only correct approach is to use the system's MIME
information.  Let me know whether setting the mailcap/mime.types prefs helps in
this case?  If it does, there is no real bug (that's not filed yet; there are
bugs on decent defaults for those prefs).  If it does not, there is a fairly
annoying bug -- the mimetype of an attachment is not determined correctly on
send.  This may also be filed, but I haven't found it yet...


adding the prefs you quoted at 2001-09-01 17:23 did the trick.

The global mime.type is read in and attachment now shows up as 
Content-Type: application/rtf;
 name="mindrover.rtf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="mindrover.rtf"

with no inline content displayed in mailbody.

So making mozilla check global mailcap/mime.type files would likely solve this.
They are obviously not checked by default yet.

Windows is another matter. Dup bug 94816 was filed with win98.

(Btw: I "discovered" the xbm mime type bug: bug 39724)
OK.  Bug 94816 reopened.  I'm marking this a duplicate of the bug on sane
default values for the helper prefs on linux.

*** This bug has been marked as a duplicate of 95504 ***
Status: NEW → RESOLVED
Closed: 23 years ago
OS: All → Linux
Resolution: --- → DUPLICATE
verified dup.
Status: RESOLVED → VERIFIED
*** Bug 126039 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.