290060 - listbox weirdness when a listitem has display none

Status: NEW

(Core :: XUL, defect)

Description

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

1. open the attached XUL document with Firefox
2. check the checkbox

Expected result: line A.2/C.2 is hidden
Actual result:   line A.2/C.2 is hidden and line A.3/C.3 is doubled ; clicking on
                 one of the two A.3/C.3 selects the two

3. then uncheck the checkbox

Expected result: line A.2/C.2 is back
Actual result:   no change...

Comment 1

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: XUL test case

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Something like a start at a patch

If figure half the day is enough to spend on this... :(

There's a whole range of issues here.  This patch fixes some, but by no means
all:

1)  nsListBoxBodyFrame::GetNextItemBox screws up when mUplinkFrame is the next
    sibling of the frame whose next sibling we're trying to create and said
next
    sibling has display:none.  It creates a second frame for the second content

    node.  That's the immediate cause of the doubling in this testase.	This
    part is easy enough to fix; with that fixed I can hide the listitem, but
    can't reshow it.
2)  Attribute changes (and this includes inline style) are ignored on list
items
    that have no frame.  I think this chunk is just bogus and should be
removed.
3)  List items with display:none aren't being stored in the undisplayed content

    map, so even with #2 fixed you can't toggle them back on.  The patch adds
    them there, but it doesn't check whether they're already in the map first.
    It should, because the listbox code will repeatedly try to construct a
frame
    for a display:none listitem.
4)  Once these are all fixed, scrolling of a listbox which has some
display:none
    kids is still horked.  In particular, the mRowsToPrepend setup simply
    doesn't work in this case.	The proper way to handle it is probably to walk

    backwards along the child list creating "top" frames until mRowsToPrepend
    goes to 0.
5)  Display:none listitems are still counted towards creating the scrollbars of

    the listbox.  I can't tell why, exactly.

So here's the question... how many separate bugs do we want on this behavior? 
;)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: More testing stuff