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

Categories

(MailNews Core :: Composition, defect, P1, critical)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 11094

People

(Reporter: momoi, Assigned: rhp)

References

()

Details

Attachments

(3 files)

** 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.
QA Contact: lchiang → momoi
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
Assignee: rhp → ftang
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
Whiteboard: need status update
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.
Assignee: ftang → nhotta
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.
Attached file I18n mail smoke test
Assignee: nhotta → rhp
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
Assignee: rhp → ftang
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
Whiteboard: need status update
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.)
Assignee: ftang → rhp
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.
Status: RESOLVED → VERIFIED
The 2 issues here are dealt with elsewhere.
Verifying as dupliacte.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.