Closed
Bug 20956
Opened 25 years ago
Closed 25 years ago
[DOGFOOD] text attachements are getting mangled..
Categories
(MailNews Core :: Composition, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M12
People
(Reporter: mscott, Assigned: jud)
Details
(Whiteboard: [PDT+])
I just sent a diff to Travis using 12/06 commercial build on windows. The diff
didn't seem to get sent as plain text. Travis said on his end that it was
treating it as html.
When I looked at the message in my Sent folder I saw some pretty suspicious
stuff. All of my diff changes appeared to be just one long continuous line of
text. I wonder if all the CRLFs got stripped out or something.
Assigning to rhp, cc jefft as I can't remember which of you guys handles this
stuff =).
I think the easiest way to see this bug is to send yourself a text file as an
attachment instead of me trying to describe it.
Marking as dogfood as sending text attachements seem to be broken.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 2•25 years ago
|
||
Do you remember the name of the file you attached? Also, what platform were you
on?
- rhp
Comment 3•25 years ago
|
||
Ok, I've reproduced the bug and see what is happening...now have to see why?
- rhp
Reporter | ||
Comment 4•25 years ago
|
||
I set the platform in the bugzilla field. This was on windows. The file I sent
did not have an extension so it was like: foo as opposed to foo.bar.
Updated•25 years ago
|
Assignee: rhp → warren
Status: ASSIGNED → NEW
Target Milestone: M12
Comment 5•25 years ago
|
||
Ok, I've figured out what the problem is here. We fetch the attachment like a
URL. It could be local "file://", remote "http://" or any valid URL. When we
start getting the data from this operation, we have the following code:
nsresult
nsURLFetcher::OnStartRequest(nsIChannel *aChannel, nsISupports *ctxt)
{
if (aChannel)
{
char *contentType = nsnull;
if (NS_SUCCEEDED(aChannel->GetContentType(&contentType)) && contentType)
mContentType = PL_strdup(contentType);
}
Necko is telling us that the content type of this data is "text/html". Looks
like the mimetype mapping in Necko is either broken or not being very accurate.
- rhp
Updated•25 years ago
|
Assignee: warren → valeski
Comment 6•25 years ago
|
||
I think there are several issues here:
- The mime type is coming out as the default, text/html.
- Maybe the default is wrong -- maybe it should be application/x-unknown
- outbound data should go through stream-converters and be based on the mime
type (bug#18424)
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•25 years ago
|
||
guessing is the wrong thing to do. we need to be sending unknown. but then
what's the url fecher supposed to do w/ unkown (default to ascii (text/plain) or
bin)?
Comment 8•25 years ago
|
||
The unknown content type handler is the one that should try to guess text/plain
or text/html and then try save-as.
Assignee | ||
Comment 9•25 years ago
|
||
we don't want a save as dialgo popping up when sending an email attatchment
though.
Comment 10•25 years ago
|
||
Are we looking into the registry to see what the OS thinks the file is? Just
wondering.
If you give me unknown (or NULL) as the content type, I have code in the
compose back end that can "sniff" the file and try to figure out what it is.
- rhp
Comment 11•25 years ago
|
||
Right...no save as dialogs...just give me NULL or unknown and I will figure it
out.
- rhp
Assignee | ||
Comment 12•25 years ago
|
||
OS mapping isn't in yet. Should protocols hand out null or application/unknown?
I'd prefer the latter.
Comment 13•25 years ago
|
||
Right, I was thinking of the 'load' case. For writing to the output stream,
there should probably be some other unknown content type handler that packages
it as binary data if all else fails.
I agree that we should be checking with the OS for mime types, but that's a
different bug. Cc'ing mscott.
Reporter | ||
Comment 14•25 years ago
|
||
I'd like to step back a quick second here. This feature used to work just fine
not that long ago. I used to send people diffs all the time using 5.0. I
probably hadn't done it in the last week or so. So my theory was that something
had regressed rather than we haven't finished implementing something to get this
working again. From that angle, has any of this stuff changed recently?
Assignee | ||
Comment 15•25 years ago
|
||
not from where I sit. URL dispatching???
Assignee | ||
Comment 16•25 years ago
|
||
just tested a fix w/ rhp. he's handling the unk content type and treating it as
plain. I'll make my changes soon.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 17•25 years ago
|
||
rhp checked his side in, I just checked mine in (12/6/99 11:00pm pac time).
Comment 18•25 years ago
|
||
Verified as fixed on win32, linux, and macos. I tested the fix using the
following builds:
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/1999-12-13-09-M12/sea
monkey32e.exe
ftp://sweetlou/products/client/seamonkey/unix/linux_glibc/2.2/x86/1999-12-13-08-
M12/netscape-i686-pc-linux-gnu.tar.gz
ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/1999-12-13-08-M12/NSMacIn
staller-M12.sea.bin
I used a diff file that Mscott provided me (thanks scott) to test sending from
5.0 seamonkey mac, windows, and linux. I viewed the message sent from each
platform on the other platforms and also viewed it in 4.7 win32 RTM.
It looks good. I was able to save the file on all platforms. I did a file
compare and the file was identical to the original. I sent messages using html
mail editor and plain text editor.
Verified as fixed.
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•