325045 - Crash when scrolling listbox with modified content [@ nsListBoxBodyFrame::GetNextItemBox]

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[:Gijs (out for now; he/him)]

[Note: first time I'm filing a crasher bug while actually knowing what's going on - please correct summary etc. as seen fit]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
(Same thing happens on current trunk Firefox on Win XP)

Steps to reproduce:

1. Create a XUL document with a two-column listbox.
2. Use the method described on http://developer.mozilla.org/en/docs/XUL:Things_I%27ve_tried_to_do_with_XUL to add enough listitems with 2 listcells to it to get a scrollbar. (through JS)
3. Remove the listbox items, and add new ones. (through JS)
3a. Notice how the listbox display doesn't update.
4. Attempt to scroll the listbox with your mouse.
4a. Notice crash.

If you execute step 3 while the listbox is invisible (display:none works), and remove the display: none afterwards, no crash occurs.

TB14481627Z
TB14462856X

James Ross should have some more detailed crash stats. It seems to crash because here: http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsListBoxBodyFrame.cpp#1185
the parentContent is null.

Comment 1

[James Ross]

Attachment: Stack at crash

Comment 2

[James Ross]

AV occurs on:  PRInt32 i = parentContent->IndexOf(prevContent);

Locals of interest:

 -aBox                   : 0x00000000`057d8f18 (class nsIFrame *)
   +0x000 __VFN_table      : 0x00000000`02ffc758 (class nsListItemFrame)
   +0x004 mRect            : (struct nsRect)
   +0x014 mContent         : 0x00000000`05882908 (class nsIContent *)
   +0x018 mStyleContext    : 0x00000000`057648d4 (class nsStyleContent *)
   -0x01c mParent          : 0x00000000`057d8e58 (class nsIFrame *)
     +0x000 __VFN_table      : 0x00000000`02ffd2d8 (class nsListBoxBodyFrame)
     +0x004 mRect            : (struct nsRect)
     +0x014 mContent         : 0x00000000`058163d0 (class nsIContent *)
     +0x018 mStyleContext    : 0x00000000`057ac2bc (class nsStyleContent *)
     +0x01c mParent          : 0x00000000`057d8d98 (class nsIFrame *)
     +0x020 mNextSibling     : (null) (class nsIFrame *)
     +0x024 mState           : 0x808020a0
   +0x020 mNextSibling     : (null) (class nsIFrame *)
   +0x024 mState           : 0x80c000a0
  aOffset                : 0
 -parentContent          : 0x00000000`00000000 (class nsIContent *)
    (null)
 -prevContent            : 0x00000000`05882908 (class nsIContent *)
   +0x000 __VFN_table      : 0x00000000`030f0f98 (class nsXULElement)
   +0x004 mNodeInfo        : (class nsINode)
   =00000000`031f0b9c nsIContent::sTabFocusModel : 7
   =00000000`031fe160 nsIContent::sTabFocusModelAppliesToXUL : 0
   +0x008 mParentPtrBits   : 0
 -result                 : 0x00000000`00000000 (class nsIFrame *)
    (null)
 -this                   : 0x00000000`057d8e58 (class nsListBoxBodyFrame *)
    mRowsToPrepend         : 0

Any more locals wanted, just ask (though I can't keep it open forever).

Comment 3

[James Ross]

I just noticed the console is absolutely *flooded* with messages like this:

  frame: TextBox(label)(-1)[value=-26.7] (057D30D4) style: 0528B248 {}
  Has parent context:  style: 057AC8B4 {}
  Should be null

It's producing one for each row nsGridRowLeaf(listitem)(-1), and one for each cell in each row.

Comment 4

[:Gijs (out for now; he/him)]

Attachment: Testcase

Testcase.

To reproduce the crash:
1. Click unhide
2. Click either of the display buttons.
3. Click hide
4. Click unhide.
5. Click the different display buttons (at least twice, I think). Notice that the contents of the listbox are no longer updated.
6. Attempting to scroll the listbox will crash the browser.

Other interesting things to try:
1. Click unhide.
2. Click hide.
3. Click unhide.
4. Clicking either of the display buttons will not have any effect.

1. Click unhide.
2. Click either of the display buttons. Notice that you can scroll the list with the scrollwheel on your mouse, if you have one.
3. Click hide.
4. Click unhide. Notice that the scrollwheel no longer works, while using the scrollbar itself does work.

Comment 5

[:Gijs (out for now; he/him)]

CC-ing roc, hoping he might have any idea if/how layout plays with this, what's going on, etc.

Comment 6

[[e-mail]]

Also CCing Boris in case he has any ideas I can chase as to why the frames for the removed elements aren't getting removed. At least, when I reproduced the crash, mFrames.FirstChild()->GetContent()->GetCurrentDoc() was null...

Comment 7

[Adam Guthrie]

*** Bug 325043 has been marked as a duplicate of this bug. ***

Comment 8

[Boris Zbarsky [:bzbarsky]]

This is another consequence of bug 282105.

Oh, and this is, generally speaking, exploitable.  Nice.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk by bug 282105

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

I followed the steps in comment 4, and beat the testcase https://bugzilla.mozilla.org/attachment.cgi?id=209968&action=view to death, but couldn't get it to crash with SeaMonkey 1.5a;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060131 SeaMonkey/1.5a

Verified FIXED

Comment 11

[Boris Zbarsky [:bzbarsky]]

Fixed on branches too, by bug 282105

Comment 12

[Jay Patel [:jay]]

v.fixed on 1.0.1 Aviary branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060220 Firefox/1.0.8, unable to get any sort of crash after trying everything mentioned in comment #4 with the testcase.

Comment 13

[Marcia Knous [:marcia]]

Using Mozilla 1.7.13 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060222, same results - no crash with the testcase in Comment 4. Adding relevant keyword.

Comment 14

[Bob Clary [:bc] (inactive)]

https://bugzilla.mozilla.org/attachment.cgi?id=209968
ff2b2 debug/nightly windows/linux no crash
verified fixed 1.8