217541 - Crash [@ 0x00000000 - IsCanvasFrame] when menupopup's onpopuphidden removes parent menulist from its parent

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[David Martinez]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827

I have an xbl component that is a simple label until you click on it, at which
point it becomes a menulist with a series of options. The onpopuphidden of this
menulist removes the menulist to replace it with the label with the new value.

On Windows (but not MacOS or Linux) this action crashes the browser.


Reproducible: Always

Steps to Reproduce:
1. Create a menulist, with a menupopup and an onhidden event handler
2. on onhidden, get the parent of the menulist and remove it.
3. Watch sparks fly.

Actual Results:  
Browser crashes.

Expected Results:  
menulist should just dissapear from the parent container.

Comment 1

[David Martinez]

Attachment: Small xul testcase on how the browser can bomb.

Save your work before clicking selecting an item on the menulist.

Comment 2

[Adam Hauner]

Confirming 2003082604/trunk/W2K -> TB23134318X

Comment 3

[Adam Hauner]

And testcase is also crashing NN 7.1 (so probably 1.4 branch) -> TB23134451W

Comment 4

[Chase Tingley]

Attachment: stacktrace

#1  0x40ff5e91 in IsCanvasFrame (aPresContext=0x87233a8, aFrame=0x876d5a4)
    at nsCSSRendering.cpp:2636
2636	  aFrame->GetFrameType(getter_AddRefs(frameType));
(gdb) p aFrame
$1 = (class nsIFrame *) 0x876d5a4
(gdb) p *aFrame
$2 = {<nsISupports> = {_vptr.nsISupports = 0x876ffbc}, mRect = {
    x = -572662307, y = -572662307, width = -572662307, height = -572662307},
  mContent = 0xdddddddd, mStyleContext = 0xdddddddd, mParent = 0xdddddddd,
  mNextSibling = 0xdddddddd, mState = 3722304989}

Cute testcase.

Comment 5

[Chase Tingley]

Updating summary.

This stack was also on bug 141590 and bug 187890, which both were fixed by bug
123049.  I'm not sure if this is therefore a layout bug, or something XUL is
doing wrong that triggers the same condition.

Stack was on linux trunk cvs pulled this morning.

Comment 6

[Brian Ryner (not reading)]

So we're passing a deleted frame around for awhile...  I don't quite understand,
offhand, why the check in ProcessRestyledFrames (nsCSSFrameConstructor.cpp, line
10009) isn't catching this.

Comment 7

[Martijn Wargers (dead)]

WFM, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050519
Firefox/1.0+

Comment 8

[Martijn Wargers (dead)]

Resolving WFM, please reopen when it still can be reproduced in current trunk build.