Closed Bug 11763 Opened 21 years ago Closed 21 years ago
Regression: Quoting in Reply/Forward of Japanese msgs is broken in Msg window body
** Observed with 8/12/99 Win32 M9 build ** This was working until a few builds ago and so this is a regression. 1. Select a JPN msg (HTML or plain)containing a Japanese header & body text with no attachment 2 [details] [diff] [review]. Now reply or forward (w/ auto auto) either under HTML or plain text mail send. 3. You see that the Message window body seems to be in raw JIS rather than in Japanese. Note: header quote is not working -- this is a known bug. But the body text quote should show in Japanese.
Severity: normal → critical
Priority: P3 → P1
Summary: Regression: Reply/Forward on Japanese msgs are broken in Msg window body → Regression: Reply/Forward on Japanese msgs are broken in Msg window body
Target Milestone: M9
Setting the priority and sedverity. This should be fixed for M9.
Assigning myself as QA.
I think the reply bug 11094 has not been fixed. Did you try us-ascii or latin1, are those working?
I'm not sure if Rich has taken out the Meta charset listening in Bug 11094. It's not clearly indicated there. I assumed that he did not take the action and in the meantime, the crash stopped occuring. Rich, please tell us -- is non-ASCII quoting supposed to work with today's build?
I didn't take out the emitting of a meta tag so this should be there. Also, plain text has been messed up the past few days...quoting was very broken. - rhp
This problem of raw JIS display in reply-forward/quote happens with both plain text and HTML mail. So this seems like a real regression and not related to the other bug, then.
BTW, Latin 1 high-bit characters are quoted OK.
Akkana did some modification few days ago to fix a conversion problem with japanese mail. Maybe this problem is a side effect of her fix. I reassign the bug to Rich as it's a composition backend issue.
Assignee: ducarroz → rhp
This is still that problem of the editor dealing with HTML that has a META tag that specifies a charset. I'll attach an example of the data that comes out of the quoting operation and just trying to load this into viewer or apprunner seem to give me lots of problems. - rhp
Summary: Regression: Reply/Forward on Japanese msgs are broken in Msg window body → Regression: Quoting in Reply/Forward of Japanese msgs are broken in Msg window body
Since what's broken is "quoting Japanese text", I'll modify the sumamry to fit the problem better.
Summary: Regression: Quoting in Reply/Forward of Japanese msgs are broken in Msg window body → Regression: Quoting in Reply/Forward of Japanese msgs is broken in Msg window body
I can see Rich's attachment using 4.5 Win32 or today's Win32 build. I think that's a correct UTF-8 html. When I saved that as a local file and tried to open it by the editor then I got problems (either not redraw or redraw with many gargabe). I am seeing the similar problem by opening Netscape JA page which has also a META tag with charset.
Saved the attachment as a URL to make it easier to test in the editor. OnEndDocumentLoad is called once (correct), so this isn't the double-load problem, but something else.
Using the smoke test data, I saw different results between local and imap. Local file, I saw any replied message got redraw problem (could be a dup of 11094). While imap, I got the same problem momoi mentioned for the second (ISO-2022-JP) and forth message (UTF-8). There may be other problem for imap. Reassign to Rich for further investigation.
There seems to be a problem with IMAP operations and getting completion calls on running URL operations. Does this work with local mail, but not IMAP. If so, this is a duplicate of a bug that jefft has on his plate. - rhp
>Does this work with local mail, but not IMAP. Not so sure because of the redraw problem, but I can see at least correct Japanese (at least no raw JIS with incorrect draw/redraw) in case of local mail.
This problem actually occcurs under both IMAP and local mail. Once the garbage is cleared out, you'll see no-Japanese strings under local mail.
Also there seems to be a difference of the following type: Under IMAP; you see raw JIS. Under local mail: you see 8-bit characters (but not Japanese) This result is obtained for reply/quoting exactly the same msg.
Ok, here is the deal. The quoting we do with IMAP is a hack that is guaranteed not to work for Japanese or any other non us-ascii text...and it didn't ever work. I am waiting on a stream routine from mscott that won't be in the product until M10. No, on POP, seems like we have 2 problems: 1 - redraw problem 2 - UTF-8 rendering problem I have no idea what the redraw problem is....we just tell the editor to load a URL and we are done. Second, the data we are telling the editor to load is the "Example of mail message quoting" data that I've attached to this bug which looks valid to me. For both these problems, I'm really not sure what I can do to fix these. I can try to trace it and debug it, but I need to get multipart related fixed and about 10 other bugs fixed before Friday when I will be leaving for sabbatical. I will try to look at it later today. - rhp
Well, IMAP reply/quote for Japanese text at least displays OK on the last pre-necko build, 7/28/99. Are you saying that this was a fluke?
Big fluke...consider yourself lucky. - rhp
Ok, I've traced this broke on the line before we call to LoadURL on the editor. I have attached this quoted HTML file to this bug. If you try to load this in viewer, you get weird behavior. When you try to load the first time, you get the repaint problem. If you just force a reload, it comes up fine. I have a feeling that there is data there after the first load, and hitting some keys in the editor gives you the repaint, but the character rendering is wrong. Frank, if this doesn't belong to you, please reassign, but it appears to be a problem loading this HTML that specifies UTF-8 in the META tag since my tests had nothing to do with mail or the editor. - rhp
There's a style sheet issue here. If you load this file in the browser, it works. If you load it in the editor, the editor starts but you see nothing in the window. But if you apply the style sheet "Editor Styles 1" (from Format->Apply Style Sheet), everything looks fine on Linux, even the Japanese text; on Mac, the Japanese text doesn't show up but everything else does.
I think there is another bug lurking in this, too. I norticed that quoting a 1-line Latin 1 msg under HTML send option actually dumps the original headers and body without any quoting marker like ">" or "|" and sends it out. The body is still Latin 1 as it arrives but the headers if they contain 8-bit Latin characters seem to be in raw UTF-8.
OK. The header bug seems to have been also reported in Bug 5493.
I saved Rich's attachment Created an attachment (id=1222) as a local HTML file and opened it with today's apprunner from Sweetlou and it displays fine for me (as Naoki also confirmed in an earlier comment.)
rhp: Don't get confused. After Necko land, a lot of thing are broken in viewer but not apprunner. > If you try to load this in > viewer, you get weird behavior. When you try to load the first time, you get > the repaint problem. If you just force a reload, it comes up fine. I just talk to haishd ~3:00 about this issue. He try to trace down a problem only happen in the viewer with Meta tag page display as blank untill hit reload. (It seems exactuly the samething you described) We trace down the problem and find out the mSHist in nsWebShell::ReloadDocument is null so it cannot find the URL to reload. Radha recently change the history cod and it probably is broken in viewer. Howerver, this is probably not the cause of the bug. You should trace this bug by checking whether the nsWebShell::ReloadDocuemnt call RefreshURL with a valid URL. BTW, is that true the current behavior looks like the same as 11094. If so, it depend on Necko to fix a notification issue. See 11094 for details.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
I did load it in apprunner and saw the same bad behavior. I was just trying to isolate the behavior away from mail/news. - rhp *** This bug has been marked as a duplicate of 11094 ***
Naoki, Rich and I just discussed teh current state of this bug and came to an agreement that this bug should have been really 2 bugs. One -- the IMAP non-ASCII quote problem which has dependency on mscott's work. This goes to rhp. Two -- The Ender problem which cannot display the mail message containing Japanese correctly though the same page can be displayed OK with Browser. This goes to akkana. Bug 11094 started out as a crashing bug and it is confusing as to what the current status is. And so it would be best to file a new bug on Two.
I'll be filing 2 new bugs.
The 2 issues here are dealt with elsewhere. Verifying as dupliacte.
You need to log in before you can comment on or make changes to this bug.