262310 - infinite loop after reordering thread pane columns with drag drop

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[David :Bienvenu]

I'm pretty sure I have the latest fixes. If I reorder my thread pane columns, I
end up in an infinite loop here, in particular, nsSprocketLayout::GetAscent
loops forever, I guess because of a circular list of next boxes...

nsIFrame::IsBoxFrame() line 1279 + 20 bytes
nsIFrame::GetNextBox(nsIFrame * * 0x0012e764) line 1326 + 20 bytes
nsSprocketLayout::GetAscent(nsSprocketLayout * const 0x0292ce48, nsIFrame *
0x030fe920, nsBoxLayoutState & {...}, int & 0x000000b4) line 1554
nsBoxFrame::GetAscent(nsBoxFrame * const 0x030fe920, nsBoxLayoutState & {...},
int & 0x000000b4) line 980 + 38 bytes
nsSprocketLayout::GetAscent(nsSprocketLayout * const 0x0292ce48, nsIFrame *
0x030fe868, nsBoxLayoutState & {...}, int & 0x00000000) line 1539
nsBoxFrame::GetAscent(nsBoxFrame * const 0x030fe868, nsBoxLayoutState & {...},
int & 0x00000000) line 980 + 38 bytes
nsSprocketLayout::GetAscent(nsSprocketLayout * const 0x0292ce48, nsIFrame *
0x030fe72c, nsBoxLayoutState & {...}, int & 0x00000000) line 1539
nsBoxFrame::GetAscent(nsBoxFrame * const 0x030fe72c, nsBoxLayoutState & {...},
int & 0x00000000) line 980 + 38 bytes
nsSprocketLayout::GetAscent(nsSprocketLayout * const 0x0292ce48, nsIFrame *
0x030fe674, nsBoxLayoutState & {...}, int & 0x00000000) line 1539
nsBoxFrame::GetAscent(nsBoxFrame * const 0x030fe674, nsBoxLayoutState & {...},
int & 0x00000000) line 980 + 38 bytes
nsSprocketLayout::GetAscent(nsSprocketLayout * const 0x0292ce48, nsIFrame *
0x030fe5bc, nsBoxLayoutState & {...}, int & 0x00000000) line 1539
nsBoxFrame::GetAscent(nsBoxFrame * const 0x030fe5bc, nsBoxLayoutState & {...},
int & 0x00000000) line 980 + 38 bytes
nsSprocketLayout::GetAscent(nsSprocketLayout * const 0x0292ce48, nsIFrame *
0x0309c180, nsBoxLayoutState & {...}, int & 0x0000012c) line 1539
nsBoxFrame::GetAscent(nsBoxFrame * const 0x0309c180, nsBoxLayoutState & {...},
int & 0x0000012c) line 980 + 38 bytes
nsSprocketLayout::GetAscent(nsSprocketLayout * const 0x0292ce48, nsIFrame *
0x0303a298, nsBoxLayoutState & {...}, int & 0x000000b4) line 1539
nsBoxFrame::GetAscent(nsBoxFrame * const 0x0303a298, nsBoxLayoutState & {...},
int & 0x000000b4) line 980 + 38 bytes
nsSprocketLayout::GetAscent(nsSprocketLayout * const 0x0292ce48, nsIFrame *
0x0303a20c, nsBoxLayoutState & {...}, int & 0x00000000) line 1539
nsBoxFrame::GetAscent(nsBoxFrame * const 0x0303a20c, nsBoxLayoutState & {...},
int & 0x00000000) line 980 + 38 bytes
nsSprocketLayout::GetAscent(nsSprocketLayout * const 0x0292ce48, nsIFrame *
0x0298d988, nsBoxLayoutState & {...}, int & 0x000000b4) line 1539
nsBoxFrame::GetAscent(nsBoxFrame * const 0x0298d988, nsBoxLayoutState & {...},
int & 0x000000b4) line 980 + 38 bytes
nsSprocketLayout::Layout(nsSprocketLayout * const 0x0292ce48, nsIFrame *
0x0298d988, nsBoxLayoutState & {...}) line 257
nsBoxFrame::DoLayout(nsBoxFrame * const 0x0298d988, nsBoxLayoutState & {...})
line 1098 + 34 bytes
nsIFrame::Layout(nsBoxLayoutState & {...}) line 799
nsStackLayout::Layout(nsStackLayout * const 0x02c15f98, nsIFrame * 0x0298d6a8,
nsBoxLayoutState & {...}) line 316
nsBoxFrame::DoLayout(nsBoxFrame * const 0x0298d6a8, nsBoxLayoutState & {...})
line 1098 + 34 bytes
nsIFrame::Layout(nsBoxLayoutState & {...}) line 799
nsBoxFrame::Reflow(nsBoxFrame * const 0x0298d6a8, nsPresContext * 0x02a28c08,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int &
0x00000000) line 854

Comment 1

[Brian Ryner (not reading)]

Attachment: patch

fixes two problems in the box ordinal code:

- newPrevSib should never be set to aChild.  It was being set to aChild in the
case where aChild is being moved to an ordinal that already has a box.	For
example, if this method is called for the box marked A below:

1 1 1 2 2 2
  B A

we should keep newPrevSib set to the box marked B.

- If aChild used to be at the front of the list, but isn't anymore, then we
need to call SetFrames to make aChild's next sibling the first child.

Comment 2

[David :Bienvenu]

thx, Brian, that fixes the problem for me.

Comment 3

[Brian Ryner (not reading)]

checked in