Closed Bug 403657 Opened 14 years ago Closed 14 years ago
[FIX]HTML list with empty second entry renders second line on top of first line
An un/ordered list renders incorrectly when the second entry is empty. ie. the HTML list: 1. Some text 2. 3. renders with the first and second line partially over each other. Test case included with and ordered list. Same behaviour with an unordered list. Tested with most recent build: Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007111304 Minefield/3.0b2pre 220.127.116.11 doesn't have this problem.
Regression range for this is: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1169516400&maxdate=1169525519 Caused by Bug 367332?
OS: Linux → All
Hardware: PC → All
+'ing w/ P4. Dbaron, please adjust priority if needed.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P4
Raised to P3; we had a lot of complaints when we had similar bugs in releases in the past.
We were actually placing the block parts of the list-items just fine. But we were positioning the bullet with its baseline at the top of the list-item. That doesn't really make much sense. Either we should put the baseline at the bottom (hard, because we haven't computed final size yet) or we should just leave the bullet right below the top padding (what this patch does). That's all in the case when the list items has no lines, of course; if it has one, we'll use its baseline.
Summary: HTML list with empty second entry renders second line on top of first line → [FIX]HTML list with empty second entry renders second line on top of first line
Target Milestone: --- → mozilla1.9 M10
Comment on attachment 290848 [details] [diff] [review] Proposed fix r+sr=dbaron. I'm presuming the bullet influences the height of the first line if it needs to, so that this will guarantee the bullet doesn't overflow (unless, say, the bullet's text overflows its frame). Though it almost seems like if a bullet contributes to the height of the block, it should be returned by GetFirstLineBaseline (or GetLastLineBaseline), even if the block is otherwise empty. Maybe that deserves a followup bug?
(Or would that be an easy fix now?)
And a reftest would be good -- comparing a bullet on an empty block to a bullet next to an , maybe?
Checked in, with reftest. Filed bug 406512 on our IRC conversation.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
The reftest fails on Mac. The empty <li>s are not as tall as the ones with an in them. :( I disabled it for now; not sure how to write a good reftest here...
You need to log in before you can comment on or make changes to this bug.