33213 - HTML from Seamonkey email not displayed correctly in Netscape Messenger 4.7

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P3)

Description

[sol]

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.

Comment 1

[Jean-Francois Ducarroz]

Reassign to rhp

Comment 2

[rhp (gone)]

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

Comment 3

[selmer (gone)]

Mail Review recommends beta2 stopper.  Adding nsbeta2 keyword.

Comment 4

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 5

[rhp (gone)]

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

Comment 6

[lchiang]

Hmm.... perhaps we should send this one to Marek's group?

Comment 7

[leger]

Putting on [dogfood+].  We need this fixed ASAP please.

Comment 8

[lchiang]

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."

Comment 9

[rhp (gone)]

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

Comment 10

[lchiang]

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."

Comment 11

[leger]

[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.

Comment 12

[rhp (gone)]

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

Comment 13

[sol]

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.

Comment 14

[Ben Bucksch (:BenB)]

IMO, we shouldn't send out CSS at all, just structural HTML. This would solve
this bug as well.

Comment 15

[rubydoo123]

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.

Comment 16

[sol]

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.

Comment 17

[Ben Bucksch (:BenB)]

> 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 :) .)

Comment 18

[Ben Bucksch (:BenB)]

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..

Comment 19

[rubydoo123]

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

Comment 20

[rubydoo123]

Attachment: screen grab of the quoted text

Comment 21

[sol]

Beth - not sure what's going on - I was just able to reproduce this bug using 
the steps I originally described in the bug.

Comment 22

[rubydoo123]

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.

Comment 23

[pmock]

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.

Comment 24

[rubydoo123]

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.

Comment 25

[pmock]

Attachment: PC Screen shot of problem

Comment 26

[pmock]

Attachment: Mac screen shot of problem

Comment 27

[scottputterman]

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.

Comment 28

[rubydoo123]

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.

Comment 29

[sol]

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?

Comment 30

[rubydoo123]

picking up the bug for the time being

Comment 31

[rubydoo123]

talked with Joe, we will attempt to figure out a solution for this situation.

Comment 32

[Joe Francis]

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?

Comment 33

[Ben Bucksch (:BenB)]

jfrancis, yes, this bug only appears in Mailnews, see comments from
[e-mail] 2000-05-18 18:13.

Comment 34

[Joe Francis]

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.

Comment 35

[rubydoo123]

added fix by date in status

Comment 36

[rubydoo123]

setting to m17

Comment 37

[Ben Bucksch (:BenB)]

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.

Comment 38

[Ben Bucksch (:BenB)]

Ops, just read on .editor, that <p> cannot contain block-level elements (but the
indention in the editor can) :-(.

Comment 39

[Kathleen :Brade]

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)

Comment 40

[Akkana Peck]

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.

Comment 41

[Joe Francis]

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?

Comment 42

[rubydoo123]

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. 

Comment 43

[Akkana Peck]

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.

Comment 44

[Joe Francis]

I'm confused.  blockquote is already what we use.  Adding style onto it is what 
caused this bug to start with.

Comment 45

[rubydoo123]

right -- so you would remove the style attribute and use just a straight 
blockquote

Comment 46

[Hixie (not reading bugmail)]

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?

Comment 47

[rubydoo123]

updated fix by date

Comment 48

[Joe Francis]

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.

Comment 49

[rubydoo123]

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.

Comment 50

[Joe Francis]

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?

Comment 51

[rubydoo123]

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.

Comment 52

[Joe Francis]

okee doke... making the change now...

Comment 53

[Joe Francis]

"fixed"

Comment 54

[fenella]

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.

Comment 55

[pmock]

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. :-)

Comment 56

[pmock]

Attachment: Sol's original test message

Comment 57

[pmock]

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.