Open Bug 333024 Opened 15 years ago Updated 5 months ago

Editor(/Compose/Composer) adds an unwanted <BR> in the last <LI> of a <UL>

Categories

(Core :: DOM: Editor, defect, P5)

x86
Windows XP
defect

Tracking

()

People

(Reporter: ferdez, Unassigned)

References

Details

(Whiteboard: DUPEME)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0

Whe you edit a HTML message using bulleted lists the generated HTML is wrong, since it puts a extra <BR> in the last list item. For example, a list with 3 items will generate HTML like this:
<ul>
  <li>one</li>
  <li>two</li>
  <li>three<br>
  </li>
</ul>

This will show an extra, empty, item, when you read the message.

Reproducible: Always

Steps to Reproduce:
1. Create a HTML mail message
2. Insert a bulleted list
3. Send message
4. Check stored message (extra item in list) and wrong HTML in message source

Actual Results:  
A message with an empty list item appears

Expected Results:  
Should not include the <BR> before the </LI> in the last item
correcting component (composer is not for mail, it is about making web pages)

please set the version of mozilla on which you see this problem and make additional helpful comments to clarify the problem since you last reported.
Assignee: composer → mail
Component: Composer → MailNews: Main Mail Window
I found this problem in composing mail AND in the Composer. 
Version: unspecified → 1.8 Branch
SeaMonkey v1.0.x is not supported anymore.

Can you reproduce with SeaMonkey v1.1.9 ?
Whiteboard: DUPEME
Version: 1.8 Branch → SeaMonkey 1.0 Branch
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008051803 Thunderbird/3.0a2pre] (nightly) (W2Ksp4)

Message Compose has bug.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008060802 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Page Composer has bug.

***

1. Add empty bulleted list:
1r.
{{
<ul>
<li><br>
</li>
</ul>
}}
Assignee: mail → nobody
Status: UNCONFIRMED → NEW
Component: MailNews: Main Mail Window → Editor
Ever confirmed: true
Product: Mozilla Application Suite → Core
QA Contact: editor
Summary: HTML mail messages including <LI> are wrongly formated → Editor(/Compose/Composer) adds an unwanted <BR> in the last <LI> of a <UL>
Version: SeaMonkey 1.0 Branch → Trunk
Duplicate of this bug: 473984
I don't think the description here covers all the issues so I'm pasting in the description from the newer dup:

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
rv:1.9.1b3pre) Gecko/20090116 SeaMonkey/2.0a3pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
rv:1.9.1b3pre) Gecko/20090116 SeaMonkey/2.0a3pre

If you are typing in a list structure (e.g.):
<ul>
  <li>item 1</li>
  <li>item 2</li>
</ul>
with your cursor at the end of item 2 in "Normal" (WYSIWIG) view

a <br> is inserted after the close </li> tag as follows:
<ul>
  <li>item 1</li>
  <li>item 2</li>
  <li><br>
  </li>
</ul>

Typing some text into the new list entry you get the following:

<ul>
  <li>item 1</li>
  <li>item 2</li>
  <li>item 3<br>
  </li>
</ul>

The problem is this extra <br> element causes many browsers to add a carriage
return in the middle of the list so list elements look like they are "double
spaced".

Note: If you add yet another item, the <br> is removed but added again to the
last item you just added.

However, adding <br> is not limited to the last item in a list.  If you put
your cursor at the end of one of the items in the list (not the last) and type
enter and type text, you'll get similar result.

For example, put your cursor after item 1 in the following:
<ul>
  <li>item 1</li>
  <li>item 2</li>
</ul>

Then type return and you get this:
For example, put your cursor after item 1 in the following:
<ul>
  <li>item 1</li>
  <li>item 1a<br>
  </li>
  <li>item 2</li>
</ul>

The list is left in this state and rendering looks bad in many browsers.

The problem is also true with tables.  For example, create a table as follows:

<table style="text-align: left; width: 100%;" border="1" cellpadding="2"
cellspacing="2">
<tbody>
<tr>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>

By default the table has <br> tags in it and they do not go away.



Reproducible: Always

Steps to Reproduce:
The examples above should describe well enough the steps to reproduce but let
me know if now and I'm happy to spell this out in detail.
Actual Results:  
See above in Details.

Expected Results:  
Composer should NOT add <br> tags as profusely as it does.  In fact, it should
only insert a <br> element if the yser types return.

I'd REALLY REALLY like to see composer have a mode where you can select to use
<p> elements exclusively when typing return instead of <br> elements.  The
preference for "Return in paragraph always creates new paragraph" seems only to
affect if you are already in a <p> element.

A big problem with <br> elements is that when you change sytle (e.g. set a
bunch of lines to an unordered or ordered list (<ol> or <ul>) or you set the
style to a heading or something, you end up with new lines where there should
not be and they are difficult to remove w/o going to the source.

Note: I have the preference of "Return in paragraph always creates new
paragraph" checked

I'd almost like to say this is a major annoyance in Composer and makes it far
less functional as a good HTML editor than it could be but I'll refrain from
setting the "Severity".

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.