Closed Bug 59460 Opened 25 years ago Closed 25 years ago

Regression: Cannot display Japanese attachments correctly

Categories

(MailNews Core :: Backend, defect, P3)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: momoi, Assigned: mscott)

References

(
URL
)

Details

(Whiteboard: [rtm++])

Attachments

(2 files)

Test cases with attachments in .zip format. Unarchive first.
40.75 KB, application/x-compressed
Details
a patch
552 bytes, patch
Details | Diff | Splinter Review
** Observedw tih 11/6/2000 Win32 and Mac builds ** There seems be a big regreesion in these 2 builds. In the Internaitonal Smoketest folder, the 3rd message has a main body and a Japanese web attachment. I am not able to display the attachment as Japanese in the mail window. It is working with 11/4/2000 Win32 build with the same profile. So this seems to be a regression in the last 2 days. The regression this big cannot be ignored. I don't think this is just Japanese. It looks like 1) Meta charset tag is ignore and 2) Menu correction is not effective. In Japan, of course, this will be near fatal blow for Mail. We need to find out what MIME parsing code changes were checked in the last 2 days.
In my opnion, this is impairment of basic functionality.
Keywords: rtm
I don't want to ship this.
I have looked at other attachments. We are failing to display Japanese HTML attachments that contain an embedded charset tag. If the page has no tag, we can either display it or correct with with the charset menu. If it has a tagm, there seems to be no way to correct it. Does this ring a bell, anyone?
Adding jefft to cc. Anyone have ideas about this yet?
well, we did change some code on Monday to stop that spam mail crash and it related to the charset tag.
Given it really works on 11/4 builds, you should start by suspecting 59203 and then 58774. 59203 stops a crasher by fixing some mime logic. 58774 changes the way we generate filenames when storing external content. Both went in since 11/4.
As we were reviewing the patch the other day, putterman and I had comments regarding the original code may not be right. So we didn't try to resolve the wrong logic. I was trying to avoid more changes but fixing the crashing problem. Looks like the original wrong implementation sometimes hit the right spot. Not crashing but rendering it right.
Kat, it doesn't look like the link to get the smoketest folder is working for me. Can you either attach it here or at least attach a message that doesn't work?
Jeff, are you looking at how to fix this? Scott is trying to get the message to repro it. He's on AIM if you need to reach him.
Yes, I am. I am trying to figure out what's the correct syntax of charset parameter embedded in an html element. Once I got that I can come up with the solution quickly.
There are 7 msgs in this folder. The following is what you get with the 11/6/2000 build. 1. Displays OK. Plain text attachment follows the main body charset. 2 - 4 : Fails to display attachments -- all with attachments with embedded charset tags 5 - 7: Displays OK or display correctable by one of the Japanese settings -- all without meta charset tag in the attached HTML pages. Correct by setting the following. 5. EUC-JP 6. Shift_JIS 7. ISO-2022-JP
Display failure in 2 -4 cannot be corrected by charset menu changes.
Changed QA contact.
QA Contact: esther → momoi
Thanks everyone for jumping on this so quickly. Kat, can you verify if this has any impact on European languages?
Attached patch a patch — — Splinter Review
Kat, with the attached patch I can view the first 5 messages but having problem with SJIS and JIS message. Is that right?
Never mind. I need to turn on the auto detect in order to view SJIS and JIS messages.
Actually, you should be able to do the following for msgs 5 - 7: a. Turn on the Auto-detect and view all of them correctly. b. Turn off the Auto-Detect and then change the charset menu as follows: 5. Change the charset menu to EUC-JP (Yahoo) 6. Change the chaset menu to Shift_JIS (SJIS no meta) 7. This one with JIS (ISO-2022-JP) should display without menu changes. (JIS no meta) Both a and b have to work properly. Please check out the scenario b) in with your fix.
With regard to Laura's question about the effect: This is very tentative because 1-byte languages seem to behave differently i this regard: 1. Non-ASCII European langs will have initial display problem which they did not have in PR3. But it looks like the problem is correctable with menu. (Not enough testing done to knowif this generalization holds to langs like Russian. There may be other un-correctable failures.) 2. On the other hand with East Asian 2-byte langs, it looks like we just fail in displaying atatchments with an embedded charset tag even if the attachment charset matches that of the main body. (Japanese, Korean, Traditional Chinese and Simplified Chinese all fail this way.) This failure is un-correctbale within Mail. The onyl way to see this type of attachments in these languages is to save it as a separate document. None of these were problematic in PR3. This is actually a huge regression in Chinese, Japanese, and Korean, it seems.
marking rtm++ please check in after r and sr.
Whiteboard: [rtm++]
Fix checked in to both trunk and branch.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
this was r=scottip and sr=mscott via aim.
I should correct my wording here. When I say "fails to display attachments", I mean that it displays but not as the intended language. When the display fails, it will look like random ASCII and Latin 1 characters.
I ended up attaching a more extensive set of test cases, but the Smoketest URl for external access is as above. In this file, only the 3rd message from the top is usable as this bug's test case.
URL: http://www.mozilla.org/quality/intl/t...
Looking at the new "2000-11-08-01-MN6" Windows build and limiting my remarks to only the fix at hand, it looks good. I have an internal test case which has 11 msgs in it. All the cases except 1 (Czech: ISO-8859-2 body and Windows-1250 attachment) work as expected now. The Czech does not work as expected with PR3, either, and so apparently the problem was there before. In any case this new problem is correctable by a menu change. ji and marina, please look at Mac and Linux with the internal test case. We also need to look at other attachment cases, just to be sure.
linux build is 2000-11-08-07.
Verified on linux 2000-11-08-07-mn6, the fix is in.
after testing the latest Mac build (2000-11-08) i can say that all messages in Kat's folder are displaying correctly.
This bug now has been verified on the branch. (11/8/2000 builds.) This should also be verified on the trunk later. It seems that there still might be some lingering problems and we probably should look at this area again, particularly with web pages that contain non-Asian charsets. Will leave that task for aother bug. What I have found is that the current builds have no regressions in this regard from M18/Beta 3. Thanks for jefft, putterman and nhotta for discussing the details of the code change and its impact.
Keywords: vtrunk
** Checked with 1/7/2001 Win32 build ** I used the attached test case file which contains 11 different attachments. There are some which don't contain meta-tags in the attachments -- these are clearly mentioned in the message body. The others contain a meta charset tag. The results of the testing is as intended. 1) If an HTML attachment contains a meta-charset tag, display works OK even without any auto-detection. 2) Other require a charset menu adjustment. Marking the fix verifierd as fixed on a trunk build.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: