Closed Bug 16931 Opened 25 years ago Closed 25 years ago

[DOGFOOD] [Regression]Cannot type into a HTML reply message

Categories

(MailNews Core :: Composition, defect, P1)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: sfraser_bugs)

References

Details

(Whiteboard: [PDT+])

Attachments

(1 file)

With a build form this afternoon (cannot test with today's build because of another identity bug, I cannot type anymore into the body when I reply to an HTML message. The message is correctly formatted and displayed but impossible to edit it. I will attach the html file that we load into the body (ender) that let us reproduce the problem using just editor. How to reproduce the problem: ---------------------------- 1) open the attached reply.html file into Editor 2) try to type something in, nothing appends!
Severity: normal → blocker
Summary: [Regression]Cannot type into a HTML reply message → [DOGFOOD] [Regression]Cannot type into a HTML reply message
We will need this for tomorrow's release build - marking a blocker.
Depends on: 16531
Whiteboard: [PDT+]
Assignee: buster → cmanske
Priority: P3 → P1
Assigning to charley based on the research below. Don't know if it's in our code or mail code, but charley's the right contact on the editor team to help fix it. From a note I just sent to phil... ============================================================================= Looks to me like somehow you're embedding a browser rather than an editor in the content area. To test this, I set a breakpoint on nsEditor::nsEditor(), and brought up the reply window. I expected to hit the constructor twice: once for the text control in the addressing area, and once for the content. I only got the first one (the stack clearly shows it's a text control and not the editor app shell.) So I don't think Joe has anything to do with this problem. I'd have charley and a mail UI/XUL person look at this, starting in the JS code that builds the reply message window.
We haven't changed the way we instanciate Ender into message compose for a while (several months!). The only difference between a new message and a reply is the .html file we load. In the first case we load a predefined file name defaultHTMLBody.html in the second case we build on the fly a n html file. As even if I am sure at 100% that we do the same, I will quickly do a test which consist to load the default body instead of the reply file during the reply to see if it works...
Assignee: cmanske → sfraser
When replying, we break at nsEditorShell constructor and ::Init, but not ::InstantiateEditor. Simon: Could you please look at this since you know more about editor startup? (And I've had my share of firedrills this week!)
Does the file being loaded have a meta tag with "charset"? There's a known problem with that.
I've just hardcoded the file we load into editor to be the default HTML body. Now when I reply to a message, I get the default body and I am able do type. The problem is somewhere else with the content of the reply file (attachment id=2317) that for some reason when loaded into editor (you can reproduce the problem without message compose), the file is correctly displayed but you cannot edit it.
Yes, it have a charset defined (the file is attached to this bug report): <br><br>Jean-Francois Ducarroz wrote:<br><BLOCKQUOTE TYPE=CITE><html><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> <html> <head><!--doctype html public "-//w3c//dtd html 4.0 transitional//en"&gt;--> </head> <body text="#000000" bgcolor="#ffffff"> <br> <br> <table border cols="1" width="100%" bgcolor="#ffffaa"> <tbody> <tr> <td> <center> <i>This message was sent by <a href="http://www.mozilla.org/mailnews">Messenger 5.0<br></a></i></center> </td></tr></tbody></table> </body> </html> </html></BLOCKQUOTE>
Yes, this seems to have come up again. On the good side, I think I am going to be able to remove libmime's generation of META tags for it's quoted output. This will help MOST of the cases, but we will still have times when inline HTML docs will be quoted into Ender and those documents could have META tags, so we will need to fix this bug for those cases. - rhp
In the current case, the META tag isn't created by my but inherited from the original message
I think that this is a dup of 16937. rpotts has that bug now.
I just tried this using 1999102208 build and it certainly is the META tag , but it really isn't an issue with charset=UTF-8. The problem is really with text/html. Shouldn't that be type=text/html? If I rewrite the META element contnent to this: <META HTTP-EQUIV="Content-Type" CONTENT="type=text/html; charset=UTF-8"> it works just fine.
I didn't think that syntax was correct. If I look at the syntax used in the Netscape Japan page, the line is: <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=x-sjis"> - rhp
well, the HTML 4.0 spec, in section http://www.w3.org/TR/REC-html40/struct/global.html#edef-META shows the character encoding example this way: <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-5"> which is how it is written out in the file, so apparently we shouldn't put in the type= the really weird thing, is that I swapped the content to this: content="charset=ISO-8859-5; text/html" and it works
*** Bug 17073 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT+] → [PDT ]
Whiteboard: [PDT ] → [PDT+]
PDT+ was accidentally changed to just PDT. I'm changing it back.
Blocks: 17025
No longer depends on: 16531
Blocks: 16531
QA Contact: lchiang → pmock
changing QA assigned to myself
Rick's changes on Sunday fixed this problem I believe. It seems to be working for me now.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Problem gone. Mark it fixed. Thanks rickg.
Actually it was the other Rick...Rick Potts =)
Status: RESOLVED → VERIFIED
Win32 (1999-10-26-09 M11) I can type into a HTML reply message now.
Blocks: 12658
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

Created:
Updated:
Size: