Closed Bug 20956 Opened 25 years ago Closed 25 years ago

[DOGFOOD] text attachements are getting mangled..

Categories

(MailNews Core :: Composition, defect, P3)

x86
Other
defect

Tracking

(Not tracked)

VERIFIED FIXED

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.
QA Contact: lchiang → pmock
Whiteboard: [PDT+]
Putting on PDT+ radar.
Status: NEW → ASSIGNED
Do you remember the name of the file you attached? Also, what platform were you on? - rhp
Ok, I've reproduced the bug and see what is happening...now have to see why? - rhp
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.
Assignee: rhp → warren
Status: ASSIGNED → NEW
Target Milestone: M12
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
Assignee: warren → valeski
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)
Status: NEW → ASSIGNED
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)?
The unknown content type handler is the one that should try to guess text/plain or text/html and then try save-as.
we don't want a save as dialgo popping up when sending an email attatchment though.
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
Right...no save as dialogs...just give me NULL or unknown and I will figure it out. - rhp
OS mapping isn't in yet. Should protocols hand out null or application/unknown? I'd prefer the latter.
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.
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?
not from where I sit. URL dispatching???
just tested a fix w/ rhp. he's handling the unk content type and treating it as plain. I'll make my changes soon.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
rhp checked his side in, I just checked mine in (12/6/99 11:00pm pac time).
Status: RESOLVED → VERIFIED
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.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.