Open Bug 179596 Opened 22 years ago Updated 2 years ago

Lists which contain consecutive list items which contain only whitespace (i.e. empty) render the list items without advancing the vertical position

Categories

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

Product:
Core
Component:
Layout: Block and Inline
Type:
defect

Tracking

()

People

(Reporter: owen, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: testcase)

Attachments

(7 files)

reporter's testcase
228 bytes, text/html
Details
screenshot of the problem
38.69 KB, image/png
Details
slightly more complex test case
1.56 KB, text/html
Details
reftests
3.89 KB, patch
Details | Diff | Splinter Review
patch 1: fix height given to bullets next to empty blocks
9.89 KB, patch
roc
: review+
Details | Diff | Splinter Review
patch 2: implement line-height quirk using bullet presence rather than HTML LI tag
8.12 KB, patch
roc
: review+
Details | Diff | Splinter Review
patch 3: make lines with bullets non-empty
5.41 KB, patch
roc
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016 If I supply the construct <OL> <LI> </LI> <LI> </LI> <LI> </LI> <LI> </LI> </OL> I would expect rendering something like 1. 2. 3. Instead, I get rendering equiivalant to: 1.\r2.\r3.\r (Notice the absence of \n). The same problem may exist with other types of lists. Reproducible: Always Steps to Reproduce: 1. Construct an HTML page with an ordered list containing multiple consecutive list items with only whitespace. 2. View the page in the Mozilla browser. Actual Results: The list item numbers were rendered over each other in the same vertical position on the page. Expected Results: Mozilla should produce each number on it's own text row. This bug is also reproducable on Mozilla 1.0.1 Linux
Attached file reporter's testcase —
this looks fine to me, linux trunk build 20021109 and 1.2b. if this worksforyou, please attach a testcase that exhibits the bug as you have described.
Also WFM in the latest Windows nightly build.
Keywords: testcase
WorksForMe using FizzillaCFM/2002110808 on 10.1.5.
three worksformes -> WORKSFORME. Note that if this is not WORKSFORME it's probably a dup of bug 54979, which I filed about two years ago...
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
I'm seeing this behaviour on FF 1.5.0.7 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7). Testcase: --- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <HTML> <BODY> <ol><li> </li><li>Text goes here</li></ol> </BODY> </HTML> --- (note spaces between <li> and </li> are important) Above testcase shows a single line with '1.' and '2.' overlapping, whereas: --- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <HTML> <BODY> <ol><li></li><li>Text goes here</li></ol> </BODY> </HTML> --- shows two separate lines. This bug should be reopened. Reading bug 54979, it looks as though a fix for that would solve this bug, but it would probably be easier to fix directly. At a guess, some code exists somewhere that ensures an empty list item has a line height associated with it; this needs to be extended to cases where the list item contains only whitespace.
Status: RESOLVED → UNCONFIRMED
Depends on: 54979
Resolution: WORKSFORME → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: Macintosh → All
Summary: Lists which contain consecutive list items which contain only whitespace render the list items without advancing the vertical position → Lists which contain consecutive list items which contain only whitespace (i.e. empty) render the list items without advancing the vertical position
Verified the bug. Running: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a6pre) Gecko/20070629 Minefield/3.0a6pre
I can reproduce the bug consistently in [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8] and it affects both UL and OL. Any LI element with just whitespace in it will lose its height (or related property), but the marker is still rendered. The result is that markers are rendered right on top of eachother. Workaround: don't write LIs with only whitespace. Ensure that either nothing or non-whitespace chars are present between LI tags. Then it's okay.
Still seeing this on today's nightly build. Probably too late to make it to FF 3 though. Just noticed it at http://developer.yahoo.com/yui/get/#script Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008052304 Minefield/3.0pre
HTML for this is: <ol> <li>A script node is appended to the target <code>window</code> for the first script file requested;</li> <li>the <code>src</code> attribute of the new script node is set to the specified URL; </li><li>the script, in a successful transaction, is loaded and executed;</li> <li>the script node's <code>load</code> event fires;</li><li> </li><li>the Get Utility checks to see if more URLs remain to be loaded; if so, it recurses to step 1; </li><li>if this was the last of the URLs specified for this transaction, the Get Utility invokes the <code>onSuccess</code> callback (if one has been specified);</li> </ol>
Finally found an appropriate bug where to file this test case. :-) Reproduces with both ordered and unordered lists, and was seen in both Firefox 2 release and Firefox 3 nightly builds. Worst case (from the attached test case) is "Ordered list with XML comment in third item (no whitespace between markup, whitespace within list item)", where the third item is completely overlapped by the forth. This issue may be somehow related with bug 179596. Versions: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1pre) Gecko/2008070106 GranParadiso/3.0.1pre
(In reply to comment #10) > This issue may be somehow related with bug 179596. Sorry, I meant bug 63741.
Attached patch reftests — — Splinter Review
Some reftests based on Helder's test case.
I think we're hitting this a lot more often now that we're stripping whitespace frames (and therefore creating fewer lines), so I think this should block 1.9.2 because many of the cases may be regressions from that whitespace-only frame stripping. However, that also makes it much easier to fix fully (the bug is actually in two places -- one for the no-lines case and one for the have-a-line case).
Assignee: layout → dbaron
Component: Layout → Layout: Block and Inline
Flags: blocking1.9.2?
QA Contact: ian → layout.block-and-inline
Actually, maybe it hasn't gotten any worse; it still should be easier to fix without regressing bug 75963.
Flags: blocking1.9.2?
So, there are three cases in the bullet placement code: 1. placing a bullet next to an otherwise empty block 2. placing a bullet next to a line 3. placing a bullet next to a line inside a block child or next to an empty block child I have patches to fix this bug for the first two cases, as well as fixing one other issue noted in an old comment. I still don't have patches for case (3); these are actually tested by some of the reftests for bug 428810 (though half of the known-failing reftests for that bug were fixed by my fix for case (1)). But I think it's worth getting my patches for (1) and (2) in; they cover the testcases in this bug and in bug 507187, though I haven't checked other duplicates.
This considers the line-height when placing a bullet next to an otherwise-empty block (floats and absolutely positioned elements don't count towards making a block non-empty).
Attachment #393689 - Flags: review?(roc)
This fixes an old "XXX" comment I wrote (I think) many years back. It makes the un-quirking of the line-height quirk be based on the presence of a bullet rather than the presence of an <li> element.
Attachment #393690 - Flags: review?(roc)
This makes lines with bullets non-empty. I don't *think* it's a problem that this doesn't kick in until after reflow, but I'm not entirely sure. (Also note that patch 1 makes blocks with bullets non-empty.) This fixes the bug in the case of bullets adjacent to otherwise-empty lines (e.g., a line with an empty inline element, as in the testcase for bug 507187)
Attachment #393691 - Flags: review?(roc)
Oh, and the other question about patch 3: how many bits do we *really* need for nsLineBox::mChildCount ?
Some notes on fixing the remainder of this bug: We currently have three cases for bullet handling (see comment 19). Based on the CSS 2.1 spec (including what it leaves undefined in the definition of list-style-position:outside but really ought to say), these should really be condensed a bit in two ways: 1. the case of a bullet associated with an empty block should really be fixed by forcing the creation of a line box and making that line box non-empty. However, our special case code for this case is probably simpler than the code needed to do that, and may well be correct enough at this point (although fixing bug 25888 for bullets may add additional complication here, so we may actually want to fix this as described) 2. the case of a bullet aligned with something in a child block, which can turn into any one of the three cases. What is needed to fix the remaining issue of this bug is make the second one of these exceptions to look more like the way it should in theory: We need to pass the logical ascent and descent of the bullet (i.e., the logical ascent is the larger of the ascent (portion of height above the baseline) of the bullet itself and the ascent computed from the block's line-height and font) down to descendants, so that they can modify their size (either block size or line size, unless we condense case (1) into the normal handling) *and* emptiness (including line emptiness) appropriately. However, when we do this, final placement of the bullet should still belong with the block that "owns" it, because that block needs to be responsible for the bullet's horizontal position. Such a bullet should not be indented to wtrap around floats that are *inside* of its block, and it should be positioned relative to the edge of its block. (However, fixing bug 25888 properly makes this complicated.)
(In reply to comment #26) > What is needed to fix the remaining issue of this bug is make the second one of > these exceptions to look more like the way it should in theory: We need to > pass the logical ascent and descent of the bullet (i.e., the logical ascent is > the larger of the ascent (portion of height above the baseline) of the bullet > itself and the ascent computed from the block's line-height and font) down to > descendants, so that they can modify their size (either block size or line > size, unless we condense case (1) into the normal handling) *and* emptiness > (including line emptiness) appropriately. Oh, and an additional problem that makes this hard: dynamically updating such interior blocks correctly, when they go from "having the bullet" to not, or vice-versa, due to dynamic changes to one of their siblings or a descendant of one of their siblings.
Would it be ok to spawn a new bug for the issues left in comment 26 and 27, and Resolve->Fixed this bug? The checkins were made, so _something_ was definitely fixed...
(In reply to comment #28) > Would it be ok to spawn a new bug for the issues left in comment 26 and 27, and > Resolve->Fixed this bug? FWIW, I'd also hint towards that. This issue seems fixed to the extend of it's original objective. Closing this one and reporting a follow-up bug IMO seemed the best choice. In my testing, attachment 105904 [details] and attachment 327609 [details] (this bug's test cases) no longer reproduce the issue using both stable 3.6.8 [1] and nightly 4.0b5pre [2], on Windows Vista SP2 (I had confirmed and attached one of the test cases in comment 10). [1] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET4.0E) [2] Mozilla/5.0 (Windows NT 6.0; rv:2.0b5pre) Gecko/20100822 Minefield/4.0b5pre ( .NET CLR 3.5.30729)
Severity: minor → S4

The severity field for this bug is relatively low, S4. However, the bug has 5 duplicates.
:jfkthame, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jfkthame)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(jfkthame)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: