Closed
Bug 8903
Opened 25 years ago
Closed 25 years ago
Japanese page display of attachment URL is broken
Categories
(MailNews Core :: MIME, defect, P3)
Tracking
(Not tracked)
M8
People
(Reporter: momoi, Assigned: nhottanscp)
References
()
Details
** Observed with 6/25/99 Win32 M8 build ** We have a message in our International Smoketest file (see URL above). Of the 5 messages we use, the 3rd one from top (or the bottom) contains an attachment which is not showing inline but only as an URL. When you click on this URL, 5.0 tries to display it in the message viewing window rather than in a browser window, which was the standard behavior in 4.x. The Japanese display of such a case is broken. It does not seem like proper conversion is taking place for display. This particular message has an atatchment encoded in Shift-JIS/CTE=B64. We should also be able to take care of EUC-JP/CTE=B64 and ISO-2022-JP/CTE= B64.
<The part about displaying in the message pane after clicking on an URL is part of another reported bug already.>
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M8
Comment 2•25 years ago
|
||
Actually, I have a guess at what's going on here. Naoki, tell me if this makes sense. This isn't an issue with the "mail.inline_attachments" pref or the content-disposition header. They are working as they should, but gecko is not displaying the output from libmime for the following reason. First, to see that we are outputting the page inline, do the following: 1 - bring up messenger 5.0 and display the problem message 2 - now bring up a 5.0 browser window and load the URL: file:///c:/temp/tempMessage.eml?header=none (note: you probably won't see anything past the URL) 3 - Do a "View Source" - notice how there is source output for the entire web page. Now, this is what I think is happening. We start decoding everything to UTF-8 and the message and the body part is encoded with charset = "iso-2022-jp". When we hit the web page, we start decoding that message to UTF-8, but there is no charset= on the part, so we fall back to the body, which is iso-2022-jp. Now, we do this conversion and output to Gecko, but the web page has a <META HTTP-EQUIV ="Content-Type" ="text/html; charset=x-sjis> line. I assume that Gecko is listening to this and trying to display UTF-8 data (which is probably wrong to begin with) as x-sjis. So, the bug about the content-disposition is invalid, but this is a problem we need to figure out. Naoki, do you have any ideas? Here is the output from libmime for the message body: < META HTTP-EQUIV ="Content-Type" ="text/html; charset=UTF-8">< !doctype html public "-//w3c//dtd html 4.0 transitional//en">< html> ã..ã..ã.¯SJISã.®ã..ã.¼ã.¸ã.§ã..ã..< br>& nbsp;< p>< A HREF ="http://home.netscape.com/ja/"> http://home.netscape.com/ja/< /A>< /html>< BASE HREF ="http://home.netscape.com/ja/">< HTML>< HEAD>< TITLE> Netcenter .Ö.æ.¤.±.»< /TITLE>< META HTTP-EQUIV ="Content-Type" ="text/html; charset=x-sjis">< META http-equiv =PICS-Label ='(PICS-1.1 "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0)'> < META http-equiv =PICS-Label ='(PICS-1.1 "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' < META HTTP-EQUIV ="Content-Type" ="text/html; charset=UTF-8">< !doctype html public "-//w3c//dtd html 4.0 transitional//en">< html> ã..ã..ã.¯SJISã.®ã..ã.¼ã.¸ã.§ã..ã..< br>& nbsp;< p>< A HREF ="http://home.netscape.com/ja/"> http://home.netscape.com/ja/< /A>< /html>< BASE HREF ="http://home.netscape.com/ja/">< HTML>< HEAD>< TITLE> Netcenter .Ö.æ.¤.±.»< /TITLE>< META HTTP-EQUIV ="Content-Type" ="text/html; charset=x-sjis">< META http-equiv =PICS-Label ='(PICS-1.1 "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0)'> < META http-equiv =PICS-Label ='(PICS-1.1 "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))'.......
Updated•25 years ago
|
Assignee: rhp → nhotta
Status: ASSIGNED → NEW
Comment 3•25 years ago
|
||
Naoki, Isn't this the same as another bug you are working on for this issue. - rhp
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 4•25 years ago
|
||
The remaining issue about this is charset auto detection accuracy (8899). There is also a charset related problem for clicking a link inside the message pane. But that is a separate problem from this bug (not attachment problem). *** This bug has been marked as a duplicate of 8899 ***
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
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
•