338 bytes, text/plain
616 bytes, patch
|Details | Diff | Splinter Review|
1013 bytes, text/plain
851 bytes, text/plain
851 bytes, text/plain
Jeff Tsai wrote: Enclosed is a patch which fixes the problem. -- Jeff Jeff Tsai wrote: I don't think anyone is aware of this problem. Since this is a multipart/alternative message libmime should always present the text/html version of the message. This apparently is a bug. -- Jeff Sol Goldfarb wrote: Is anyone aware of the attached problem? Apparently, Netscape 6 is incorrectly displaying the contents of some messages. If someone is familiar with this issue, can you please reply to Craig Haft (email@example.com). Thanks, Sol -------- Original Message -------- Subject: Fwd: problem with NS 6.0 mail Date: Tue, 7 Nov 2000 16:58:25 EST From: CLHaft@aol.com To: firstname.lastname@example.org Got vacation reply from kmurray which suggested you. Craig Haft -- Sol Goldfarb Group Product Manager, Netscape Client Product Marketing Telephone: (650) 937-2931 AIM Screen Name: nscpgold Subject: problem with NS 6.0 mail From: CLHaft@aol.com Date: Tue, 7 Nov 2000 16:50:25 EST To: email@example.com ! I'm the developer/manager for the AOL IMAP server. Our QA group noticed a problem in test that looks like a bug in Netscape 6. If the message being read looks something like: To: firstname.lastname@example.org From: email@example.com Subject: test MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=1 --1 Content-Type: text/x-aol; charset=iso-8859-1 Some plain text --1 Content-Type: text/html; charset=iso-8859-1 Some HTML text --1-- Then NO text is displayed to the user, and not attachment is available. The only way for the user to see the text is to view the page source. We were expecting the client to ignore the "text/x-aol" piece and only display the "text/html" part. If the first part is changed to "text/plain" or "x-foo/x-aol", then the HTML part IS displayed. It appears as thought the problem is caused when Netscapes sees a "text" part with and unrecogized "x-aol" subtype. FYI, the text/x-aol type is used by some of the AOL newletters and is used to contain text that is formatted for our older (non-HTML capable) clients. It actually may contain a limited subset of HTML that the older clients support, so it is not really plain text. From RFC 2046 4.1.4. Unrecognized Subtypes Unrecognized subtypes of "text" should be treated as subtype "plain"as long as the MIME implementation knows how to handle the charset.Unrecognized subtypes which also specify an unrecognized charsetshould be treated as "application/octet- stream". Craig Haft attachment.htm Content-Type: text/html Content-Encoding: 7bit nsmail-5.eml Content-Type: message/rfc822 Content-Encoding: 7bit Index: mimemalt.cpp =================================================================== RCS file: /cvsroot/mozilla/mailnews/mime/src/mimemalt.cpp,v retrieving revision 1.4 diff -u -r1.4 mimemalt.cpp --- mimemalt.cpp 1999/11/06 03:32:43 1.4 +++ mimemalt.cpp 2000/11/08 06:18:28 @@ -213,7 +213,7 @@ are themselves unknown. */ - MimeObjectClass *clazz = mime_find_class (ct, sub_hdrs, self->options, PR_TRUE); + MimeObjectClass *clazz = mime_find_class (ct, sub_hdrs, self->options, PR_FALSE); PRBool result = (clazz ? clazz->displayable_inline_p(clazz, sub_hdrs) : PR_FALSE); bugalt.txt Content-Type: text/plain Content-Encoding: 7bit
thanks Jeff. I'll put this on the stack :-) - rhp
Marking [rtm need info] to get r=/sr=/testing done. Please do that and move to [rtm+] when ready. I hope there isn't another respin, but I'd like this to be ready if there is.
Adding reviewers ....
Let me explain how the fix work. To handle multipart/alternative message we need to go through all the alternative part to cache the most content rich part that our client can handle. We are failing on text/x-aol part. We couldn't find a mime class to handle it due to the strict rule of exact matching the content-typ when calling mime_find_class(...., PR_TRUE). Since text/x-aol is a generic text/ content type we could simply let it handle by MimeUntypedText class. Passing in mime_find_class(...., PR_FALSE) does the job correctly and smoothly. It's the right and correct fix.
Does 4.x have the same problem? From the code, I would expect that it does.
It could be. I don't have the dogbert tree handy to check with.
Can't you just save the sample message to a local folder and read it with 4.x? I'll try that myself.
4.x did have the same problem, which is reassuring. But Rich should really be the reviewer here...
Yes, this looks good. r: rhp Also, I will be out doing Mozilla evangelism today so if Jeff can spearhead this, that would be great. - rhp
Yes, I'll do that. There is one more thing taht we need to test with. We need to add more alternative type in the message for example, ftp type.
Did some more test on adding more content-type to it. We still have problems of handling content types other than "text/". For all "text/" subtypes, we can handle it correctly. mscott can you give a sr=?
how does passing PR_FALSE change the semantic behavior of mime_find_class? What does this argument do? thanks!
The boolean variable specifies whether to find a mime class exactly matching the content-type/subtype we reguested or a mime class which can handle content-type/ in general. For this particular case, if we pass in PR_TRUE then we are requesting for exact mime class which can handle text/x-aol. Unfortunately, we don't specific implementing this experimental content-type. However, for general text content-type we do have a generic text mime class to handle it. Passing in PR_FALSE still go through the logic of finding an exact matching class. In addition if we found a mime class which can handle text/ content-type we return it back to the caller.
ahh cool, so we still look for an exact match first and if we can't find it we use a general text class. Thanks for the explanation! sr=mscott
I don't believe this bug warrants a respin nor do I think it's an rtm type bug. Let's catch it in 6.5 and check it into the tip.
Agreed, just trying to make it ready.
This doesn't seem like it would handle the case where a particular alternative just cannot be handled, but a higher fidelity one has not yet been processed. Seems like we should validate ALL parts before bailing out shouldn't we?
We are not handle all sorts of alternative types at the moment but we do for all the "text/" alternative types. That's probably the most general case especially people using our client. The way multipart/alternative works is the message starts with the lowest to highest content rich alternative part. We have to parse all parts and pick one that the mail client can handle.
Okay, the patch I proposed does fix all the problems. I just had a not well formatted message to test with. (see new example message for better idea) For parts we cannot handle we return MimeExternalObjectClass which is equivalent to content-type "application/octal-stream". This a correct fix for all cases. Simple and does the right thing.
rtm-, a server solution will be required for this.
I don't understand "a server solution will required for this."
Sorry, I should have said we can't afford to respin for this fix. The CD3 build has been certified and we don't have any time to try again.
I thought you were saying that MTA should provide the solution. Thanks for the clarification.
Fix checked in to the trunk only. Mark it as fixed.
Changing qa assign to firstname.lastname@example.org
OK using apr17 commercial trunk build win98