194831 - unpopulated/empty <LI> is not rendered unless redrawn (doctype dependent)

Status: RESOLVED WORKSFORME

(Core :: Layout: Block and Inline, defect, P5)

Description

[Felix Miata]

trunks

Above URL has four unpopulated <LI> tags. 2003022408 Linux and 2003022412 OS/2
display them as bullets beside whitespace, just like IE6. Win 2003022408 renders
as if they didn't exist.

Comment 1

[Josh Birnbaum]

Working with Moz 1.3b on WinXP.  If I have my window at full-screen (1024x768),
I see the bug.  If I shrink it down, I do see the empty <LI>'s.

Comment 2

[Boris Zbarsky [:bzbarsky]]

The size does not matter.  What matters is that a reflow will make them show up
(eg open/close the sidebar).  But initially they are hidden.
Felix, could you possibly create a minimal testcase?  (remove all HTML not
needed to reproduce the bug).

Comment 3

[Felix Miata]

Attachment: HTML 4.01 loose testcase

Comment 4

[Felix Miata]

Attachment: HTML 3.2 testcase - note reduced top margin compared to 4.01

Comment 5

[Felix Miata]

Attachment: HTML 4.01 strict testcase

Comment 6

[Felix Miata]

Attachment: Screenshot of 4.01 strict testcase

Strict behaves different than the others, not depending on a window resize.,
but always doing it wrong

Comment 7

[Felix Miata]

All my tests done at 1024x768. No difference if charset statement is omitted
from head. Amplifying summary to include doctype and redraw.

On further study, this is not OS dependent. The original URL (4.01 loose)
behaves differently than the testcases. Fullscreen, the empties are not
displayed until redraw. Windowed, the empties are always displayed. I think the
difference is that the original doesn't fit entirely in the viewport regardless
like the testcases do.

Except for top margin difference, the 4.01 loose and 3.2 testcases behave the
same.  Regardless whether opened fullscreen or windowed, the empties are omitted
until redraw.

4.01 strict doesn't care about redraw. It always displays a siamese. I suppose
maybe this should be a separate bug.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Looks like a inline box model thing; the Strict testcase especially is
weird-looking.

Comment 9

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

This is at least partly caused by the incorrect fix for bug 75963 (which should
have been fixed by associating the bullet with a different frame).  Making
pfd->GetFlag(PFD_ISBULLET) (in addition to the current text frame condition)
force zeroEffectiveSpanBox to false helps a little, though.

Comment 10

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

I think this is the same problem that's causing the uneven spacing on
http://www.w3.org/2003/Talks/03-bostontp-dahl/slide1-0.html

Comment 11

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

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

Comment 12

[Adam Roben]

Confirming HTML 4.01 strict testcase shows overlapping bullets
HTML 4.01 loose and HTML 3.2 testcases only show 3 items, each with a bullet.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040113 Firebird/0.8.0+

Comment 13

[Simon Paquet [:sipaq]]

Is this the same bug as bug 383289? If yes, we can dupe bug 383289 to this one.

Comment 14

[Sylvestre Ledru [:Sylvestre]]

Decreasing the priority as no update for the last 2 years on this bug.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage 
about the priority meaning.

Comment 15

[Boris Zbarsky [:bzbarsky]]

The testcases all work now.