45464 - Mozilla mishandles nested lists' end tags causing malformed lists.

Status: VERIFIED DUPLICATE of bug 50261

(Core :: DOM: HTML Parser, defect, P3)

Description

[Nathan Adams]

Reproduceability: Every time

Steps to reproduce:
1. browse to http://cherokeewebsolutions.com/mozillatests/mb_lists20000713.html
2. read page description
3. view page source to verify html is correct :-)

Expected results:
1. First list should be ordered (numbered) with an unordered (bulleted) nested list
2. Second list should be unordered with an ordered nested list

Actual results:
Both lists contain the wrong type of bulleting (numbers/bullets).

Summary & Possible Cause
Mozilla appears to be ignoring and/or mishandling the nested lists' end tags.

Comment 1

[Jeffrey Baker]

Confirming on Linux with build 2000071308.  Note that this is also
DTD-dependent:  if you declare the document as HTML 4.01 Strict, the first list
is all ordered with no nesting, and the second list is all unordered with no
nesting.  This example is attached.  Possibly related to Bug 42388, the
collection bug for general DTD horkage.

Comment 2

[Jeffrey Baker]

Attachment: Example of lists under HTML 4.01 Strict

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The HTML in the testcase Jerry Baker posted is actually invalid (by
inspection).  Nested lists must be *within* the LI element.  You can't have one
list directly inside another.

However, there probably is some sort of a bug here...

Comment 4

[Marc Attinasi]

Distribution of Clayton's bugs: please triage these and share the joy...

Comment 5

[Marc Attinasi]

Distribution of Clayton's bugs: please triage these and share the joy...

Comment 6

[Jeffrey Baker]

Eh, you are right.  The HTML in the attachment is not valid.  My mistake.
Adding the required <LI> elements make the page render almost the same way as NN
4.74, with the exception that 4.74 inserts a newline and an indent between the
bullet/number and the nested list, while Mozilla inserts only an indent.
Perhaps this is WFM?

Comment 7

[Pierre Saslawsky]

Not WFM: the page at the URL above shows the problem in quirks mode.
Reassigned to Parser/harishd.

Comment 8

[harishd]

In quirks mode, what the parser does seems to be reasonable.  

Now the question is...should we fix this?  Comments?

In my opinion this is a WONTFIX.

Comment 9

[harishd]

*** This bug has been marked as a duplicate of 50261 ***

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Harish - do you mind either leaving this bug open or making bug 50261 public?  
I can't see the new bug.

Comment 11

[harishd]

Ya sure. Will reopen this bug. Since bug 50261 is beta3+ I'll talk to rickg in 
marking 50261 a dup of this bug and put it in the beta3+ list.

Reopening per david's request.

Comment 12

[rickg]

stealing this, and marking a dup of 50261, which is fixed in my tree.

Comment 13

[Hixie (not reading bugmail)]

*** This bug has been marked as a duplicate of 50261 ***

Comment 14

[Scott Brodmerkle]

Verified dupe.