71716 - list bullets revert to browser font defaults under various circumstances

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[kaldari]

I tried several different font tags and CSS definitions, but I couldn't get the
ordered list numbers to render in anything besides Times 16 (unless I changed my
browser defaults). The only font setting it seems to be able to inherit from the
html is color.

Comment 1

[kaldari]

maybe I'm smoking something, but it seems to be working now and I can't
reproduce the bug anymore. Maybe it was just a glitch caused by low ram
conditions or maybe there was a problem with my html. I'll play around with it
some more and try to reproduce the bug again (and come up with a simpler test case).

Comment 2

[kaldari]

It turns out this bug is far more specific than I first thought. The bug only
occurs when there is an unclosed tag inside a list item somewhere on the page.
Please look at the new test URL to see what I'm talking about:
http://test.moses.com/support/netmerchant/conventions2.html

Comment 3

[kaldari]

This bug may be related to work being done on bug 4522.

Comment 4

[kaldari]

I changed the summary to more narrowly define the bug and I moved the test case
to a new URL. I also set up a comparison page which is exactly the same as the
test case except that the closing italic tag is in the same list item as the
opening italic tag. This comparison page does not, therefore, exhibit the bug
shown in the test case. BTW, I've only tested this bug on a mac (moz 0.8), but I
assume it renders the same on other platforms. Could someone confirm this?

Comment 5

[kaldari]

whoops, forgot to say where the comparison page is. It's at
http://www.flamingbug.com/mozillabugs/listbulletsnobug.html. This is the page
that doesn't exhibit the bug.

Comment 6

[kaldari]

This bug also appears if a secondary list inside a normal list contains a list
item whose contents wrap to a new line.

Comment 7

[Bradley Hart]

I'm seeing this also, Mac OS 8.6 build 2001031910. Marking NEW.

Comment 8

[kaldari]

I have created a better set of test cases which should help narrow this bug down
a bit.

The first page is http://www.sitemason.com/newtour/mozbug.html
On this page you should notice that the bullets are rendering in the browser
default font size and line-height, rather than the CSS specified font size and
line-height. This is incorrect behavoir. It is also interesting to note that if
you load this page from cache, it renders correctly; hit reload and the bug
reappears.

The second page is http://www.sitemason.com/newtour/moznobug.html
The HTML of this page is exactly the same as the previous page, except that
there are 1 fewer characters (the z at the end of the final list item has been
omitted). This page does not exhibit the buggy behavoir. If you try adding
another character anywhere in the HTML, the bug reappears, so perhaps there is
some type of memory threshold to this bug.

The third page is http://www.flamingbug.com/mozillabugs/moznobug.html
The HTML of this page is exactly identical to the HTML of the first page, but
the bug does not appear. If I shift-reload this page, however, the bug appears.
Normal reloading reverts it back to its original correct state. The only
difference between this page and the first (that I can think of) is that this
page is on a different server).

With all these clues, I'm sure someone should be able to figure out what the
problem is. Please fix this bug, as it keeps reaccurring for me and is driving
me batty. Thanx.

Comment 9

[kaldari]

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

Comment 10

[kaldari]

Can someone test this bug on Linux or Windows? Thanx.

Comment 11

[Christopher Aillon (sabbatical, not receiving bugmail)]

Moving to OS -> All, Platform -> All.

I see this still on Linux and Win32. 20010721 builds

Comment 12

[anthonyd]

not a table specific bug, sending to owner.

Comment 13

[R.K.Aa.]

bug 38174 and bug 110360 related

Comment 14

[Jesse Ruderman]

Attachment: another testcase

Comment 15

[Jesse Ruderman]

IE is the only other browser that makes list bullets not match up with list 
text.  It really looks silly.

Comment 16

[kaldari]

Actually IE handles list bullets correctly from my experience. Mozilla is the 
only browser I know of that exhibits this behavoir, which is surpising since 
Gecko is supposed to be best HTML rendering engine out there. This is 
also a frustrating bug because there is no work around. I just have to 
accept that most of the pages I create with lists are going to look retarded 
under Mozilla. I'm really disappointed that this bug has been nominated 
for 1.1 rather than 1.0. How can we say that Mozilla is release quality with 
a sloppy HTML layout bug like this?

Comment 17

[Boris Zbarsky [:bzbarsky]]

There _is_ a workaround.  style li:before directly

Comment 18

[kaldari]

Mozilla doesn't seem to fully support the li:before CSS2 attribute. In fact the
only part of li:before that Mozilla does seem to support is 'content', although
even that isn't handled correctly. So, to restate my point: there is no
workaround, Mozilla's list redendering sucks.

Comment 19

[kaldari]

This bug appears to be fixed now.

Comment 20

[kaldari]

I haven't been able to reproduce this bug since April. Marking FIXED.

Comment 21

[Jesse Ruderman]

Should be WFM, not FIXED.

Comment 22

[Jesse Ruderman]

WFM per reporter's comments.