203727 - list numbering rendering is skewed

Status: VERIFIED FIXED

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

Description

[rubydoo123]

Tested using build 2003042808 on win2K

1. open composer
2. select the numbered list icon from the toolbar and enter the following:
one[enter]
two[enter]
three[enter]
four[enter]
nine[enter]
ten[enter]
eleven[enter]
five[enter]
six[enter]
seven[enter]
eight
3. select 'nine,' 'ten,' and 'eleven' and press the indent icon on the toolbar

Actual results: item numbers 7 & 8 are shifted to the left and are not
vertically aligned with other numbers

Expected: the vertical alignment to be correct. Attaching a screen grab

Comment 1

[rubydoo123]

Attachment: screen shot of vertical misalignment

Comment 2

[William Lipp]

Attachment: Items 7 and 8 misaligned - text is down one line from number

This is a different type of misalignment, but it also happens on exactly items
number 7 and 8.  The html code for the page will be attached next.

Comment 3

[William Lipp]

Attachment: HTML code creating the misaligned page

This code creates the misaligned page.	Page renders properly in Internet
Explorer.

Comment 4

[William Lipp]

A workaround for my misalignment examples is to put the <LI> tags AFTER the <A
NAME=> tags.  This suggests that my additional example is really a different bug
with the NAME Anchor counting towards the line fill.

Comment 5

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 6

[Mats Palmgren (inactive)]

This is actually a Layout bug...

Comment 7

[Mats Palmgren (inactive)]

Attachment: reftest.diff

Comment 8

[Mats Palmgren (inactive)]

Attachment: Like so?

When the list item ordinal changes, mark the bullet frame dirty rather than
invalidating its area.

Comment 9

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

Comment on attachment 312999 [details] [diff] [review]
Like so?

The bullet is always a child of the item, right?

r+sr=dbaron

Comment 11

[Mats Palmgren (inactive)]

(In reply to comment #9)
> (From update of attachment 312999 [details] [diff] [review])
> The bullet is always a child of the item, right?

The bullet frame always has the list item block frame as parent.
An inside bullet frame is in the normal flow child list, an outside bullet
is not.  Both are stored in the 'mBullet' member.

Comment 12

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

In theory, an inside bullet need not be a child (but rather some other type of descendant), if the block's first normal child is another block.  I'm not sure if we implement that, though.

Comment 13

[Mats Palmgren (inactive)]

AFAICT, it's always a direct child:
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsBlockFrame.cpp#6395
and other parts of this file depends on that...

Comment 14

[Mats Palmgren (inactive)]

http://hg.mozilla.org/mozilla-central/rev/cbef246880d3
http://hg.mozilla.org/mozilla-central/rev/243e6d4ef884

-> FIXED

Comment 16

[Daniel Veditz [:dveditz]]

We're using "wanted" for prospective blockers (and a slightly different meaning for security bugs), and a cosmetic change doesn't make the cut. Looks like a safe patch, though, so you could try an approval request. Doesn't meet the strict criteria, but might catch mconnor on a good day.

Comment 18

[Tony Chung [:tchung]]

Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090130 Minefield/3.2a1pre.  It's also been verified on 1.9.1branch, but the keyword was changed over in bug 418574