[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.

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).

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.

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.

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

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...

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

This is another consequence of bug 282105. Oh, and this is, generally speaking, exploitable. Nice.

Fixed on trunk by bug 282105

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

Fixed on branches too, by bug 282105

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.

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.

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