100930 - [LIST] Bullet taking its own line (unclosed anchor <a><li>)

Status: RESOLVED DUPLICATE of bug 200170

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

Description

[Ben Roberts]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4+)
Gecko/20010920
BuildID:    2001092003

(Triage warning: This looks like, but I think actaully is *not* a duplicate of
bug 36854.)

The bullet for the first item in an unordered list is sometimes taking its own line.

A good example is http://www.mozilla.org/xpapps/performance/#Trends

Reproducible: Always
Steps to Reproduce:
1. Start a recent build of mozilla (seen on Windows 2000)
2. Visit http://www.mozilla.org/xpapps/performance/#Trends
3. View source and verify that this is happening with an ordinary <li> with a
<ul> as its immediate parent.
4. Open page in Composer and notice that when you 'view source' and scroll to
the same bit of html, it's added in an extra <a name> <li> and <br>! 

Actual Results:  List item bullet for 'Browser benchmark test description' takes
its own line. Further down the page notice same behaviour under 'Team contact
info' and 'Related sites'.

Expected Results:  Put the link 'Browser benchmark test description' on the same
line as its bullet mark.

Bug 36854 covers this happening when there is something like a heading tag
inside the <li>, but this is happening even with ordinary text. Also note this
quote from [e-mail] towards bottom of bug 36854:

"This bug only effects <LI> that are not immediate children of a list <UL> or
<OL> for example.  So this is not a P1. Downgrading to P2. The author has a
straightforward workaround:  wrap the proper list type around the list items.
Supporting malformed documents isn't a top priority for the next few weeks, and
the risk to fix would be moderate, so marking Future."

This *doesn't* apply to the curent case as far as I can see (see example URL and
its source)

Also, bug 36854 is quite an old bug wheras I've only noticed this on recent builds. 

Ergo, am entering as new bug...

Comment 1

[Ben Roberts]

Attachment: test case

Comment 2

[Ben Roberts]

I think this effect is happening due to the interaction of an unclosed <a name>
anchor preceding the unordered list and the first list item being an <a href>.
If you close the <a name> then this problem goes away.

Since I think <a name> anchors should strictly speaking be closed, then is a bug
with the page html. BUT I suspect there are quite a lot of unclosed <a name>
anchors out there so mozilla should maybe handle this better. 

Comment 3

[Marc Attinasi]

Harish, is this a parser fixup issue?

Comment 4

[Ferdinand]

seeing this on win2k 2001092109 (cvs)

Comment 5

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 6

[Mats Palmgren (inactive)]

This is the contents of Testcase #2:
<a name="Contact">
<ul>
    <li><a href="">Embedding</a>
</ul>

Comment 7

[Marc Attinasi]

Accepting for Moz 1.0

Comment 8

[Mats Palmgren (inactive)]

See also bug 102370 for a similar problem with DL lists.

Comment 9

[Marc Attinasi]

Looks like parser residual-style-fixup-mania - here is the content model for the
testcase #2:

html@02EEAD70 refcount=8<
  head@02EEF200 refcount=2<
    title@0178FAF0 refcount=2<
      Text@0178F9A0 refcount=2<Testcase for bug 100930>
    >
  >
  body@0178F8E0 refcount=3<
    Text@02FF44E0 refcount=3<\n\n\n>
    a@02FF43E0 name=Contact refcount=3<
      Text@02FF4290 refcount=3<\n>
    >
    ul@02FF5F80 refcount=3<
      Text@02FF5F20 refcount=3<\n>
      a@02FF5E80 name=Contact refcount=4<
        Text@02FF5D30 refcount=3<    >
        li@02FF5C10 refcount=4<
        >
      >
      a@02FF59F0 href= refcount=3<
        Text@02FF5920 refcount=3<Embedding>
      >
      Text@02FF5BB0 refcount=3<\n>
    >
    Text@02FF5800 refcount=3<\n\n\n>
  >
>

Notice that the named anchor is closed before the UL, then opened again inside
the UL. The one inside the UL has the LI in it, but that is closed before the
link that is suppossed to be in the LI, so in fact the link is not even part of
the LI - and the LI is empty.

Over to parser to look at - layout cannot make anything different of this content.

Comment 10

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 11

[Oliver Klee]

Bug 121376 may be related.

Comment 12

[Mats Palmgren (inactive)]

*** Bug 130682 has been marked as a duplicate of this bug. ***

Comment 13

[harishd]

*** Bug 121376 has been marked as a duplicate of this bug. ***

Comment 14

[Mats Palmgren (inactive)]

*** Bug 149958 has been marked as a duplicate of this bug. ***

Comment 15

[harishd]

I can allow the anchor to contain UL ( rather block level elements ) and that
will fix this bug. However, it will break if the named achor was replaced with
an HREF. That's, the anchor will point to the wrong location. So, for the
proposed fix to work I need help from layout ( to make sure that the inner
anchor points to the correct location).

Chris, Kevin?

Comment 16

[Heikki Toivonen (remove -bugzilla when emailing directly)]

[was 1.1beta]

Comment 17

[Mats Palmgren (inactive)]

*** Bug 170175 has been marked as a duplicate of this bug. ***

Comment 18

[Mats Palmgren (inactive)]

*** Bug 161562 has been marked as a duplicate of this bug. ***

Comment 19

[Mats Palmgren (inactive)]

*** Bug 171494 has been marked as a duplicate of this bug. ***

Comment 20

[Mats Palmgren (inactive)]

*** Bug 173351 has been marked as a duplicate of this bug. ***

Comment 21

[Mats Palmgren (inactive)]

*** Bug 185528 has been marked as a duplicate of this bug. ***

Comment 22

[Mats Palmgren (inactive)]

*** Bug 216912 has been marked as a duplicate of this bug. ***

Comment 23

[Mats Palmgren (inactive)]

*** Bug 219565 has been marked as a duplicate of this bug. ***

Comment 24

[Nathan Horne]

Attachment: test case #3

Comment 25

[Nathan Horne]

See test case #3.  Unless I'm doing something wrong, this bug occurs even if the
anchor element is closed before the ul element.  The anchor element has to be
closed with an explicit </a> (instead of unclosed or empty ie <a ... />) for the
list layout to be correct.

Comment 26

[Mats Palmgren (inactive)]

<a ... /> does not actually close the element in HTML.

Comment 27

[Mats Palmgren (inactive)]

*** Bug 259655 has been marked as a duplicate of this bug. ***

Comment 28

[Mats Palmgren (inactive)]

*** Bug 257726 has been marked as a duplicate of this bug. ***

Comment 29

[Jonathan Perez]

Unclosed <A> tags seem to be responsible for a lot of rendering problems, here's
another one.  Perhaps these should be merged into a single bug?

Note that even using a strict XHTML DTD does not make XML style tag closings count:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<body>

<a name="foot" />
<code><a href="#">not monospaced because of unpaired anchor tag</a></code>

<br />

<a name="foot2"></a>
<code><a href="#">monospaced because of paired anchor tag</a></code>


</body>
</html>

Comment 30

[Erik Fabert]

*** Bug 276223 has been marked as a duplicate of this bug. ***

Comment 31

[Mats Palmgren (inactive)]

*** Bug 277987 has been marked as a duplicate of this bug. ***

Comment 32

[Blake Kaplan (:mrbkap) (inactive)]

Marking as a DUPE of a bug that I saw earlier. Technically bug 200170 is a dupe
of this (since it's a lot newer).

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