Closed Bug 33213 Opened 25 years ago Closed 25 years ago

HTML from Seamonkey email not displayed correctly in Netscape Messenger 4.7

Categories

(MailNews Core :: Composition, defect, P3)

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

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: sol, Assigned: mozeditor)

Details

(Whiteboard: [nsbeta2+][dogfood-][7/21])

Attachments

(4 files)

screen grab of the quoted text
67.82 KB, image/jpeg
Details
PC Screen shot of problem
10.58 KB, image/gif
Details
Mac screen shot of problem
15.98 KB, image/gif
Details
Sol's original test message
1.40 KB, text/plain
Details
If you send an HTML message from Seamonkey mail and read the message in Netscape Messenger 4.7, the message is not displayed correctly in Messenger 4.7 - lines overwrite other lines, making the message unreadable. Build ID: 2000-03-23-06-nb1b, commercial, on WinNT Steps to reproduce: 1. Launch Seamonkey 2. Launch Mail (Tasks | Mail) 3. Open the compose window ("New Msg" on Mail toolbar) 4. Address the message to yourself 5. Enter text in the body of the message (using the indent controls on the formatting toolbar) that looks like this. This is a message to show how message elements overlap when created in Seamonkey Mail and read in Messenger 4.7 Indented this line using Format | Increase indent A new line where I continue the indent I stopped the indenting for this line of the message. 6. Send the message - when prompted "Send in HTML Only" 7. Read the message in Seamonkey Note: The message contents look as you entered them in Step 5 8. Read the message in Messenger 4.7 Expected: The message contents look as you entered them in Step 5 Actual: The message contents are unreadable. The two indented lines are drawn at the top of the message - overlaying the first line of the message. Note: If you then reply to this message using Messenger 4.7, the contents of the replied message are displayed correctly in the 4.7 composition window.
Reassign to rhp
Assignee: ducarroz → rhp
I know what is causing this...its blockquote tags with absolute style coordinates. We send this from Seamonkey and everything aside from Communicator can deal with it just fine. I'm not so sure how we "fix" this one. - rhp
Status: NEW → ASSIGNED
Target Milestone: --- → M17
Mail Review recommends beta2 stopper. Adding nsbeta2 keyword.
Keywords: nsbeta2
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
QA Contact: lchiang → pmock
I'd like the PDT team to look at this again. The bug here really lies in Netscape 4.x's libmime. The culprit is the "margin-top: 0pt;" style attribute on the BLOCKQUOTE tags that surround indented text. To really FIX this problem, we would have to fix it in 4.x since what we send it totally valid. It display's fine in Outlook and Seamonkey and the HTML displays fine in 4.x...just not when it is run through libmime. - rhp
Whiteboard: [nsbeta2+]
Target Milestone: M17 → M18
Hmm.... perhaps we should send this one to Marek's group?
Putting on [dogfood+]. We need this fixed ASAP please.
Keywords: dogfood
Whiteboard: [dogfood+][nsbeta2-]
from phil: "It's fine to ask Marek, but I also wonder whether we should prevent Seamonkey from sending stuff which doesn't work in 4.x."
I need this looked at by PDT again. It would be a real hack to prevent us from sending this stuff. Can you guys make a call. - rhp
Whiteboard: [dogfood+][nsbeta2-]
I've emailed Marek: "I'm not sure if we'll need 4.7 to do any modifications due to this bug. Just a fyi for now."
[nsbeta2+] for beta2. Fix should not be done on the 4.7 side. Seamonkey fix. [dogfood-] ALSO, if you can show this happens alot, we can consider dogfood.
Whiteboard: [nsbeta2+][dogfood-]
Hi Sol, This is more of a product managment issue to get this fix into 4.7, don't you think? If so, just flop it back to me, but I'm not sure what I should do with it. - rhp
Assignee: rhp → sol
Status: ASSIGNED → NEW
Rich - the problem with fixing in 4.x is that users have already installed millions of copies of 4.x. The only impact we could make is on copies of 4.x that are installed in the future, but before users begin adopting Seamonkey. I would expect future 4.x installations to be a small percentage of the installed base of Netscape users, so fixing 4.x would leave most 4.x users with garbled messages from Seamonkey. I'm wondering if the Ender folks might have any ideas for making a Seamonkey solution that's less of a hack. cc:ing beppe.
IMO, we shouldn't send out CSS at all, just structural HTML. This would solve this bug as well.
using blockquote is the appropriate HTML to use for indentation. When this was included in mail compose, there was numerous discussion on this and it was decided to move forward using the blockquote with the style attribute. As we move forward with seamonkey, more and more CSS will be included within the compose application. Using Blockquote with style attribute is not a hack, it is the appropriate thing to do, the hack was using dd for the indentation. If it is acceptable, we could remove the style attribute and then allow for the indentation on both the left and right margin. The style attribute was included to override the right indentation.
Beth - if we use blockquote only (without the style attribute), then would we get an additional level of *both* left and right indent for each indent inserted by the user? Seems like you'd end up with a very skinny text area by the time you got to your 3d or 4th indent level. In any event, we really need to find a way to remedy this in Seamonkey. For many months, we will have more 4.x users than Seamonkey users, and for folks not familiar with HTML, it will appear that Seamonkey is generating "bad" formatting.
> using blockquote is the appropriate HTML to use for indentation. I don't want to start a flamewar, but that's not correct. <quote src="http://www.w3.org/TR/REC-html40/struct/text.html#h-9.2.2"> The usage of BLOCKQUOTE to indent text is deprecated in favor of style sheets. </quote> I doubt, that indention is at all appropriate for HTML. It is formatting, not structure. (OK, I'm a hardliner :) .)
rhp wrote in the beginning: > The culprit is the "margin-top: 0pt;" style attribute > on the BLOCKQUOTE tags that surround indented text. But beppe wrote: > The style attribute was included to override the right indentation. What is correct? Anyway, did you try to alter the formatting slightly? E.g. you could use div instead of blockquote, |margin| instead of |margin-top| etc..
Akkana and I have been sneding messages back and forth, I'm using 4.7 and she is using 6.0 -- I don't see a problem. It works just fine for me
Beth - not sure what's going on - I was just able to reproduce this bug using the steps I originally described in the bug.
No, we cannot use div, it does really bad stuff, that is why we chose blockquote. Blockquote is the correct element to use for indents in this manner. We are encasing a users comments in the blockquote -- because it is a quote, it is the text of someone else. The spec states this about Q and BLOCKQUOTE: "These two elements designate quoted text. BLOCKQUOTE is for long quotations (block-level content)and Q is intended for short quotations (inline content) that don't require paragraph breaks." The stated behavior/usage of the blockquote is exactly what we need to do. And the spec further states that: "Visual user agents generally render BLOCKQUOTE as an indented block." Which is what we need to do, so the originally or quoted text is offset from the response. We needed to provide an alternative solution tot he use of the div element and the bogus attribute being used in blockquote. We tried type=cite in blockquote, we had numerous issues with that. Look at bug 16085 for a discussion about the use of divs and blockquotes. Let me go back and try it again with Akkana to see if I can get this to reproduce.
I can reproduce this problem if I view the seamonkey message under Communicator 4.72 under Windows and Macintosh. The problem does not occur under Communicator 4.74 under Windows or Macintosh. Note: the problem appeared solved in 4.74 recently because, the problem still occurs in the Mac communicator 4.73 RTM. I will attach some screen shots of the problem.
I see the problem. If you do drop the margin-top, you will get line feed above each line. The margin settings are relative to the window not the surrounding text, that is why the text overrides other text. If you decide that removing the top-margin is the right thing to do, that may affect Composer functionality. I will need to investigate the ramifications that will surface there.
We should make a decision about what we want to do with this so that we can get it off of Sol's list and onto an engineer's! I agree this looks bad, but how often does this happen to people? I've received about 3-4 emails that I can remember where this has happened which isn't very much. Beppe, you mentioned that this may affect Composer's functionality if we make this work in 4.x. In what way? My feeling is that if we are doing the right thing in mozilla and there's no other way around except by doing the wrong thing that I'd prefer not to have to build in backwards compatibility forever. But if it turns out that many people are going to see this a lot, then it would be worth it to take the change. Do we have any idea how common it is to do this in email? Most people I know don't go beyond using bold and italics in their html mail to me.
at this point, we have one set of editing rules used within the editor. I'll talk with Joe today to see if we can do the wrong thing to satisfy the 4.7 mail issues and continue to do the right thing for the rest of the application.
I have both sent emails from Seamonkey that folks using Communicator 4.7 could not read, and I have been on the receiving end of such messages. Unfortunately, when this problem occurs, the message contents are typically unreadable. Since most end users don't know to view the source of the message, this problem is the equivalent to data loss for many users. While I want Seamonkey to format email messages "correctly", we need to preserve backward compatibility with 4.x through the Seamonkey release. When we get good adoption of Seamonkey, then we can re-visit. Beppe - Can I reassign to you?
picking up the bug for the time being
Assignee: sol → beppe
talked with Joe, we will attempt to figure out a solution for this situation.
Assignee: beppe → jfrancis
do we know what versions exactly are affected? I dont have access to my mail while I'm here at the machack conference, and when I bring up examples in browser windows, I dont see the problem. I'm using 4.5 on the mac. If you just open a document with one of these "margin: 0 0 0 40px " blockquotes, does it render wrong? Or is it only when viewed in mail?
Status: NEW → ASSIGNED
jfrancis, yes, this bug only appears in Mailnews, see comments from rhp@netscape.com 2000-05-18 18:13.
I could fix this if divs worked in 4.x email. I could do indention by creating a div with an appropriate amount of margin-left style. I might do this anyway even though divs cause trouble in 4.x, just becasue the trouble they cause isn't as bad as the trouble we have in this bug.
added fix by date in status
Whiteboard: [nsbeta2+][dogfood-] → [nsbeta2+][dogfood-][8/2]
setting to m17
Target Milestone: M18 → M17
I suggest to use <p> instead of <div>. <p> is very similar to <div>, but without the problems in 4.x. It might add some vertical whitespace for UAs not honoring CSS, but that's no problem IMO.
Ops, just read on .editor, that <p> cannot contain block-level elements (but the indention in the editor can) :-(.
Not to add fuel to the fire but... Over the past 3 years of running 4.x for mail, browsing, editing, etc., I have gotten hundreds of e-mails which were not readable in 4.x mail. Most of these were NOT generated by SeaMonkey. So why do we need to "fix" SeaMonkey? Isn't the workaround if 4.x of saving the message and opening in a browser good enough? I've had to do that for years... (and expect to have to keep doing that whenever I use 4.x to read e-mail)
Really? I very seldom get email that I can't read in 4.x (and 95% of the ones I do get are Word attachments). When I do get mail 4.x can't read, I almost always send mail back to the sender suggesting that they check their mail settings to send something more generic (like plaintext) or, if that won't work, consider changing to a different mailer that's more interoperable. I hope we won't put our users in a position where their friends ask them not to use our mailer because it sends out non-backwards-compatible messages.
I suggested to Beth last week that we use <div> with a left margin, on the theory that: 1) it's good html 2) though it breaks 4.x, it does so in a less harmful way (the 4.x user will be able to read the mail, they just won't be able to split the mailquote in the part that is indented). But there is one downside. In a client that doesn't support css at all, at least blockquote will be indented. It will have unneeded top, right, and bottom margins, but it will be indented. The div on the other hand will yield no indention on clients that don't supoprt css. thoughts?
I suggested we use blockquote, which is good html, but the user will get indents on left and right and top and bottom margin. However, they will get the indent. I believe it is a good solution for this particular issue.
I'm with Beth -- let's use blockquote, so it works in older mailers, and we can always add style on the blockquote, so we can fine-tune the view for those using Mozilla and other modern apps.
I'm confused. blockquote is already what we use. Adding style onto it is what caused this bug to start with.
right -- so you would remove the style attribute and use just a straight blockquote
We could always override the default style for BLOCKQUOTE in the mail default stylesheet, right? That would cause Seamonkey Mail to display the blockquote as we originally intended, and it would still work in 4.x (and OE et al). Right?
updated fix by date
Whiteboard: [nsbeta2+][dogfood-][8/2] → [nsbeta2+][dogfood-][7/21]
overriding the style has problems of it's own. If you don't also do it composer people get very confused. If you _do_ do it in composer, they still get very confused: when the layout is suddenly different when they view their page in any browser (including our own). All of the solutions propsed so far have major problems. I don't know what to do. So far using divs with margin-left seems best, but it still has a major downside: non-css-savvy mail clients and browsers will simply see no indention at all.
Joe -- the least invasive is the use of the blockquote: 1. all browsers can interpret it 2. all mail clients that read html can interpret it the downside -- the mail clients get top and margin spacing, that is acceptable. Please ustilize the blockquote for this function.
Ok, we already use blockquote. So I assume you mean take out the css margin settings on it. I just want to make sure we all understand what this imnplies, because it doesn't imply what you say. It won't be: "the mail clients get top and margin spacing". It will be EVERYBODY gets top and margin spacing. Including people just trying to make web pages with composer. Is this acceptable?
yes, blockquote is a block element and should behave like other block elements. If we can get this change in for beta 2, we can see what the feedback is and then either leave as is for rtm or try another approach for beta3. In any event we won't know how folks will react until we give it a try.
okee doke... making the change now...
"fixed"
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
While I try to verify this bug... I found that indent does not work in editor and have informed Sujay to file a bug in his area. So this bug cannot be verified until bug 46395 is fixed.
Verified as fixed on branch builds of win32, linux, and macos. Win32 commercial seamonkey build 2000-080205-m17 Linux commercial seamonkey build 2000-080204-m17 Macos commercial seamonkey build 2000-080204-m17 Verified as fixed under IMAP and local mail. I still had sol original test message. :-)
Status: RESOLVED → VERIFIED
I should mention that I viewed my test messages that I created in seamonkey using Communicator 4.7. Communicator 4.74 doesn't exhibit the original problem.
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: