Closed Bug 20677 Opened 25 years ago Closed 25 years ago

[CRASHER] Content with no document causes crash on reflow.

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: rginda, Assigned: waterson)

References

Details

(Keywords: crash, Whiteboard: [HAVE FIX Reporter please check in latest build)

Attachments

(3 files)

Simplified testcase
2.27 KB, text/plain
Details
Same file but with an XML MIME type
2.36 KB, text/xml
Details
proposed fix
1.22 KB, patch
Details | Diff | Splinter Review
To reproduce (sorry, this isn't reduced at all): Start chatzilla (www.mozilla.org/projects/rt-messaging/chatzilla) attach to efnet (/a efnet) join a large channel (/j linux) join another channel (/j chataway) wait "a little while" for some content to be appended to the chat window. swap between the channels by clicking on the toolbuttons. *crash* #0 0x40f4607b in nsTextFrame::Reflow (this=0x870d0c0, aPresContext=0x859e2a0, aMetrics=@0xbfff9ee8, aReflowState=@0xbfff9f18, aStatus=@0xbfffa98c) at nsTextFrame.cpp:2823 #1 0x40f291dd in nsLineLayout::ReflowFrame (this=0xbfffaa24, aFrame=0x870d0c0, aNextRCFrame=0xbfffa0f8, aReflowStatus=@0xbfffa98c, aMetrics=0x0) at nsLineLayout.cpp:955 #2 0x40f24071 in nsInlineFrame::ReflowInlineFrame (this=0x875d918, aPresContext=0x859e2a0, aReflowState=@0xbfffa170, irs=@0xbfffa0f8, aFrame=0x870d0c0, aStatus=@0xbfffa98c) at nsInlineFrame.cpp:489 #3 0x40f23ba1 in nsInlineFrame::ReflowFrames (this=0x875d918, aPresContext=0x859e2a0, aReflowState=@0xbfffa170, irs=@0xbfffa0f8, aMetrics=@0xbfffa140, aStatus=@0xbfffa98c) at nsInlineFrame.cpp:347 #4 0x40f23935 in nsInlineFrame::Reflow (this=0x875d918, aPresContext=0x859e2a0, aMetrics=@0xbfffa140, aReflowState=@0xbfffa170, aStatus=@0xbfffa98c) at nsInlineFrame.cpp:274 #5 0x40f291dd in nsLineLayout::ReflowFrame (this=0xbfffaa24, aFrame=0x875d918, aNextRCFrame=0xbfffa350, aReflowStatus=@0xbfffa98c, aMetrics=0x0) at nsLineLayout.cpp:955 #6 0x40f24071 in nsInlineFrame::ReflowInlineFrame (this=0x88144a0, aPresContext=0x859e2a0, aReflowState=@0xbfffa3c8, irs=@0xbfffa350, aFrame=0x875d918, aStatus=@0xbfffa98c) at nsInlineFrame.cpp:489 #7 0x40f23ba1 in nsInlineFrame::ReflowFrames (this=0x88144a0, aPresContext=0x859e2a0, aReflowState=@0xbfffa3c8, irs=@0xbfffa350, aMetrics=@0xbfffa398, aStatus=@0xbfffa98c) at nsInlineFrame.cpp:347 #8 0x40f23935 in nsInlineFrame::Reflow (this=0x88144a0, aPresContext=0x859e2a0, aMetrics=@0xbfffa398, aReflowState=@0xbfffa3c8, aStatus=@0xbfffa98c) at nsInlineFrame.cpp:274 #9 0x40f291dd in nsLineLayout::ReflowFrame (this=0xbfffaa24, aFrame=0x88144a0, aNextRCFrame=0xbfffa5a8, aReflowStatus=@0xbfffa98c, aMetrics=0x0) at nsLineLayout.cpp:955 #10 0x40f24071 in nsInlineFrame::ReflowInlineFrame (this=0x8746088, aPresContext=0x859e2a0, aReflowState=@0xbfffa620, irs=@0xbfffa5a8, aFrame=0x88144a0, aStatus=@0xbfffa98c) at nsInlineFrame.cpp:489 #11 0x40f23ba1 in nsInlineFrame::ReflowFrames (this=0x8746088, aPresContext=0x859e2a0, aReflowState=@0xbfffa620, irs=@0xbfffa5a8, aMetrics=@0xbfffa5f0, aStatus=@0xbfffa98c) at nsInlineFrame.cpp:347 #12 0x40f23935 in nsInlineFrame::Reflow (this=0x8746088, aPresContext=0x859e2a0, aMetrics=@0xbfffa5f0, aReflowState=@0xbfffa620, aStatus=@0xbfffa98c) at nsInlineFrame.cpp:274 #13 0x40f291dd in nsLineLayout::ReflowFrame (this=0xbfffaa24, aFrame=0x8746088, aNextRCFrame=0xbfffa800, aReflowStatus=@0xbfffa98c, aMetrics=0x0) at nsLineLayout.cpp:955 #14 0x40f24071 in nsInlineFrame::ReflowInlineFrame (this=0x88ee4a0, aPresContext=0x859e2a0, aReflowState=@0xbfffa878, irs=@0xbfffa800, aFrame=0x8746088, aStatus=@0xbfffa98c) at nsInlineFrame.cpp:489 #15 0x40f23ba1 in nsInlineFrame::ReflowFrames (this=0x88ee4a0, aPresContext=0x859e2a0, aReflowState=@0xbfffa878, irs=@0xbfffa800, aMetrics=@0xbfffa848, aStatus=@0xbfffa98c) at nsInlineFrame.cpp:347 #16 0x40f23935 in nsInlineFrame::Reflow (this=0x88ee4a0, aPresContext=0x859e2a0, aMetrics=@0xbfffa848, aReflowState=@0xbfffa878, aStatus=@0xbfffa98c) at nsInlineFrame.cpp:274 #17 0x40f291dd in nsLineLayout::ReflowFrame (this=0xbfffaa24, aFrame=0x88ee4a0, aNextRCFrame=0xbfffb5a4, aReflowStatus=@0xbfffa98c, aMetrics=0x0) at nsLineLayout.cpp:955 #18 0x40efa45b in nsBlockFrame::ReflowInlineFrame (this=0x8710808, aState=@0xbfffb514, aLineLayout=@0xbfffaa24, aLine=0x87e0ba0, aFrame=0x88ee4a0, aLineReflowStatus=0xbfffa9db "") at nsBlockFrame.cpp:3685 #19 0x40efa172 in nsBlockFrame::DoReflowInlineFrames (this=0x8710808, aState=@0xbfffb514, aLineLayout=@0xbfffaa24, aLine=0x87e0ba0, aKeepReflowGo) at nsBlockFrame.cpp:3576 #20 0x40ef9fa3 in nsBlockFrame::DoReflowInlineFramesAuto (this=0x8710808, aState=@0xbfffb514, aLine=0x87e0ba0, aKeepReflowGoing=0xbfffb2f4, aLineReflowStatus=0xbfffb1f7 "\002") at nsBlockFrame.cpp:3521 #21 0x40ef9d96 in nsBlockFrame::ReflowInlineFrames (this=0x8710808, aState=@0xbfffb514, aLine=0x87e0ba0, aKeepReflowGoing=0xbfffb2f4) at nsBlockFrame.cpp:3470 #22 0x40ef8535 in nsBlockFrame::ReflowLine (this=0x8710808, aState=@0xbfffb514, aLine=0x87e0ba0, aKeepReflowGoing=0xbfffb2f4, aDamageDirtyArea=1) at nsBlockFrame.cpp:2675 #23 0x40ef7bde in nsBlockFrame::ReflowDirtyLines (this=0x8710808, aState=@0xbfffb514) at nsBlockFrame.cpp:2435 #24 0x40ef60e0 in nsBlockFrame::Reflow (this=0x8710808, aPresContext=0x859e2a0, aMetrics=@0xbfffb8a4, aReflowState=@0xbfffb7e0, aStatus=@0xbfffcac8) at nsBlockFrame.cpp:1490 #25 0x40ef2b0c in nsAreaFrame::Reflow (this=0x8710808, aPresContext=0x859e2a0, aDesiredSize=@0xbfffb8a4, aReflowState=@0xbfffb7e0, aStatus=@0xbfffcac8) at nsAreaFrame.cpp:289 #26 0x40f03b75 in nsContainerFrame::ReflowChild (this=0x8713c50, aKidFrame=0x8710808, aPresContext=0x859e2a0, aDesiredSize=@0xbfffb8a4, aReflowState=@0xbfffb7e0, aX=0, aY=0, aFlags=1, aStatus=@0xbfffcac8) at nsContainerFrame.cpp:605 #27 0x40f4ea7d in nsScrollPortFrame::Reflow (this=0x8713c50, aPresContext=0x859e2a0, aDesiredSize=@0xbfffbb18, aReflowState=@0xbfffb9c4, aStatus=@0xbfffcac8) at nsScrollPortFrame.cpp:419 #28 0x40f03b75 in nsContainerFrame::ReflowChild (this=0x87139e0, aKidFrame=0x8713c50, aPresContext=0x859e2a0, aDesiredSize=@0xbfffbb18, aReflowState=@0xbfffb9c4, aX=0, aY=0, aFlags=3, aStatus=@0xbfffcac8) at nsContainerFrame.cpp:605 #29 0x40f4c9cc in nsGfxScrollFrameInner::ReflowFrame (this=0x8710870, aPresContext=0x859e2a0, aDesiredSize=@0xbfffbb18, aReflowState=@0xbfffbc00, aStatus=@0xbfffcac8, aFrame=0x8713c50, aAvailable=@0xbfffbb10, aComputed=@0xbfffbb10, aResized=@0xbfffbb0c, aIncrementalChild=@0xbfffbb94) at nsGfxScrollFrame.cpp:1210 #30 0x40f4cbb2 in nsGfxScrollFrameInner::ReflowScrollArea (this=0x8710870, aPresContext=0x859e2a0, aDesiredSize=@0xbfffc838, aReflowState=@0xbfffbc00, aStatus=@0xbfffcac8, aHscrollbarNeedsReflow=@0xbfffbba0, aVscrollbarNeedsReflow=@0xbfffbb9c, aScrollAreaNeedsReflow=@0xbfffbb98, aIncrementalChild=@0xbfffbb94) at nsGfxScrollFrame.cpp:1276 #31 0x40f4b6fc in nsGfxScrollFrame::Reflow (this=0x87139e0, aPresContext=0x859e2a0, aDesiredSize=@0xbfffc838, aReflowState=@0xbfffbc00, aStatus=@0xbfffcac8) at nsGfxScrollFrame.cpp:462 #32 0x410d9dd4 in nsBoxFrame::FlowChildAt (this=0x8711d08, childFrame=0x87139e0, aPresContext=0x859e2a0, desiredSize=@0xbfffc838, aReflowState=@0xbfffbfb8, aStatus=@0xbfffcac8, aInfo=@0x871a950, aRedraw=@0xbfffbea8, aReason=@0xbfffbe04) at nsBoxFrame.cpp:1123 #33 0x410d9121 in nsBoxFrame::FlowChildren (this=0x8711d08, aPresContext=0x859e2a0, aDesiredSize=@0xbfffc838, aReflowState=@0xbfffbfb8, aStatus=@0xbfffcac8, rect=@0xbfffbf64) at nsBoxFrame.cpp:670 #34 0x410d8dc4 in nsBoxFrame::Reflow (this=0x8711d08, aPresContext=0x859e2a0, aDesiredSize=@0xbfffc838, aReflowState=@0xbfffbfb8, aStatus=@0xbfffcac8) at nsBoxFrame.cpp:562 #35 0x410d9dd4 in nsBoxFrame::FlowChildAt (this=0x8711818, childFrame=0x8711d08, aPresContext=0x859e2a0, desiredSize=@0xbfffc838, aReflowState=@0xbfffc370, aStatus=@0xbfffcac8, aInfo=@0x871aa58, aRedraw=@0xbfffc260, aReason=@0xbfffc1bc) at nsBoxFrame.cpp:1123 #36 0x410d9121 in nsBoxFrame::FlowChildren (this=0x8711818, aPresContext=0x859e2) at nsBoxFrame.cpp:670 #37 0x410d8dc4 in nsBoxFrame::Reflow (this=0x8711818, aPresContext=0x859e2a0, aDesiredSize=@0xbfffc838, aReflowState=@0xbfffc370, aStatus=@0xbfffcac8) at nsBoxFrame.cpp:562 #38 0x410d9dd4 in nsBoxFrame::FlowChildAt (this=0x872f3a0, childFrame=0x8711818, aPresContext=0x859e2a0, desiredSize=@0xbfffc838, aReflowState=@0xbfffc798, aStatus=@0xbfffcac8, aInfo=@0x8730368, aRedraw=@0xbfffc618, aReason=@0xbfffc574) at nsBoxFrame.cpp:1123 #39 0x410d9121 in nsBoxFrame::FlowChildren (this=0x872f3a0, aPresContext=0x859e2a0, aDesiredSize=@0xbfffc838, aReflowState=@0xbfffc798, aStatus=@0xbfffcac8, rect=@0xbfffc6d4) at nsBoxFrame.cpp:670 #40 0x410d8dc4 in nsBoxFrame::Reflow (this=0x872f3a0, aPresContext=0x859e2a0, aDesiredSize=@0xbfffc838, aReflowState=@0xbfffc798, aStatus=@0xbfffcac8) at nsBoxFrame.cpp:562 #41 0x40f03b75 in nsContainerFrame::ReflowChild (this=0x8731338, aKidFrame=0x872f3a0, aPresContext=0x859e2a0, aDesiredSize=@0xbfffc838, aReflowState=@0xbfffc798, aX=0, aY=0, aFlags=0, aStatus=@0xbfffcac8) at nsContainerFrame.cpp:605 #42 0x40f193fa in RootFrame::Reflow (this=0x8731338, aPresContext=0x859e2a0, aDesiredSize=@0xbfffc988, aReflowState=@0xbfffc8e0, aStatus=@0xbfffcac8) at nsHTMLFrame.cpp:328 #43 0x40f03b75 in nsContainerFrame::ReflowChild (this=0x872fd10, aKidFrame=0x8731338, aPresContext=0x859e2a0, aDesiredSize=@0xbfffc988, aReflowState=@0xbfffc8e0, aX=0, aY=0, aFlags=0, aStatus=@0xbfffcac8) at nsContainerFrame.cpp:605 #44 0x40f4ab35 in ViewportFrame::Reflow (this=0x872fd10, aPresContext=0x859e2a0, aDesiredSize=@0xbfffcb1c, aReflowState=@0xbfffca28, aStatus=@0xbfffcac8) at nsViewportFrame.cpp:526 #45 0x40f1ac17 in nsHTMLReflowCommand::Dispatch (this=0x885da60, aPresContext=0x859e2a0, aDesiredSize=@0xbfffcb1c, aMaxSize=@0xbfffcb00, aRendContext=@0x87f1220) at nsHTMLReflowCommand.cpp:144 #46 0x40f3642d in PresShell::ProcessReflowCommands (this=0x8617108) at nsPresShell.cpp:1649 #47 0x40f336b3 in PresShell::ExitReflowLock (this=0x8617108, aTryToReflow=1, aDoSynchronousReflow=1) at nsPresShell.cpp:708 #48 0x40f37bb7 in PresShell::ContentAppended (this=0x8617108, aDocument=0x85a1ee8, aContainer=0x86f5e3c, aNewIndexInContainer=0) at nsPresShell.cpp:2099 #49 0x4094dc21 in ?? () from /home/rginda/src/mozilla_HEAD/mozilla/dist/bin/components/librdf.so #50 0x40f576ad in nsGenericHTMLContainerElement::AppendChildTo ( this=0x86f5e44, aKid=0x876021c, aNotify=1) at nsGenericHTMLElement.cpp:2960 #51 0x40f56854 in nsGenericHTMLContainerElement::InsertBefore (this=0x86f5e44, aNewChild=0x8760210, aRefChild=0x0, aReturn=0xbfffcd08) at nsGenericHTMLElement.cpp:2617 #52 0x40f56fc0 in nsGenericHTMLContainerElement::AppendChild (this=0x86f5e44, aNewChild=0x8760210, aReturn=0xbfffcd08) at nsGenericHTMLElement.cpp:2803 #53 0x40f71c62 in nsHTMLDivElement::AppendChild (this=0x86f5e30, aOldChild=0x8760210, aReturn=0xbfffcd08) at nsHTMLDivElement.cpp:52 ... The following patch prevents the crash, and produces a little more information: ndex: nsTextFrame.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/base/src/nsTextFrame.cpp,v retrieving revision 1.198 diff -u -r1.198 nsTextFrame.cpp --- nsTextFrame.cpp 1999/11/30 22:16:12 1.198 +++ nsTextFrame.cpp 1999/12/03 08:45:48 @@ -2819,6 +2819,10 @@ // Setup text transformer to transform this frames text content nsCOMPtr<nsIDocument> doc; mContent->GetDocument(*getter_AddRefs(doc)); + if (!doc) { + NS_WARN_IF_FALSE(0, "Content has no document."); + return NS_ERROR_FAILURE; + } nsCOMPtr<nsILineBreaker> lb; doc->GetLineBreaker(getter_AddRefs(lb)); nsTextTransformer tx(lb, nsnull); The following information is printed to the console when the warning is tripped: WARNING: Content has no document.: '0', file nsTextFrame.cpp, line 2823 nsLineLayout: Text(0)@0x88a1398 metrics=-559038737,-559038737! nsLineLayout: Text(0)@0x88a1398 didn't set whad -559038737,-559038737,-559038737,-559038737! nsLineLayout: Inline(span)(2)@0x88afa68 metrics=-559038737,225! nsLineLayout: Inline(span)(2)@0x88afa68 didn't set whad -559038737,225,180,45! nsLineLayout: Inline(span)(0)@0x8894640 metrics=-559038735,255! nsLineLayout: Inline(a)(110)@0x8894600 metrics=-559038735,255! nsLineLayout: Inline(a)(0)@0x8a289f8 metrics=-559038675,255! Area(div)(0)@0x8738460: line=0x8a28a38 xmost=-559038675 The failure trips quite a few times if you leave the app running, always with the same debug output. I'd be happy to help reproduce this.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
I don't know what chatzilla is, but I need a real test case (HTML or XML) that reproduces the problem. I'm wondering if chatzilla is using an old version of the layout engine. We had a problem with generated/anonymous content not having a valid document pointer but that problem has been fixed. Or so we think.
Chatzilla is an IRC client implemented in mozilla. (follow the link) This was build from cvs last night around 8pm. I assure this bug is not invalid, and is not fixed. Please call me at 3230, and I will be happy to come over and demonstrate it for you.
I believe you that the bug occurs. However, it's not reasonable for me to have to get the chatzilla client and jump through hoops to reproduce the problem. Problems that can be reproduced in viewer or apprunner are fine.
The issue here is that I get about 20 new bugs a day, and I do not have time to spend 2 hours on every bug trying to isolate and track down the problem. If it can be reproduced in sample HTML or XML I will be happy to look at it
Chatzilla is pure XUL and JS (ignoring its tiny XPConnencted bare-sockets "libbs" netlib). It's part of the Mozilla project, checked in under mozilla/extensions/irc. Rginda, is it in the Task menu yet? /be
Not part of the tasks menu yet. It is built and installed by default on windows. On Linux, configure --with-extensions=irc. No dice on Mac. To start it, launch apprunner, and visit resource:///irc/tests/index.html I'm working on a smaller testcase. In the meantime, is there any harm in checking if the document is valid before using it, maybe only #ifdef DEBUG? This little check brings my MTBF in stress cases up from one minute to about an hour.
OK, I think this testcase demonstrates what's going on. The issue seems to be adding content to a container which is not actually part of a document. (makes sense, no?) In this testcase, two html:tables are dynamically created (k1 and k2), one of which (k1) is inserted in the html:div named "kontent" onload. Clicking the "Insert 1 k1" button inserts one row into the k1 table. "Insert 1 k2" does likewise for k2. The "Swap Content" button removes whichever table (k1 or k2) is currently contained by the "kontent" div, and inserts the other one. After loading the testcase, Click "Insert 1 k1" Click "Insert 1 k2" Click "Swap Content" For me, that results in an immediate: PreCondition: "You can't dereference a NULL nsCOMPtr with operator->()." (mRawPtr != 0) at file ../../dist/include/nsCOMPtr.h, line 546 Break: at file ../../dist/include/nsCOMPtr.h, line 546 Program received signal SIGSEGV, Segmentation fault.
Attached file Simplified testcase —
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Very good. Thank you.
Severity: normal → critical
Status: REOPENED → ASSIGNED
Assignee: troy → rginda
Status: ASSIGNED → NEW
The test case doesn't work. It generates the following in theconsole when you click one of the buttons: JavaScript Error: TypeError: document.getElementById is not a function URL: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3295 LineNo: 69 JavaScript Error: TypeError: document.getElementById is not a function URL: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3295 Vidur informs me that "document.getElementById" isn't implemented yet for XML documents, because it is DOM level 2 which hasn't yet been ratified.
Try a XUL MIME type: it's a XUL file, and XUL has the document.getElementById that we need. If I save that file as "3200.xul" and then open it in apprunner, click a few times on k2, swap, a few on k1, swap...I get the crash: PreCondition: "You can't dereference a NULL nsCOMPtr with operator->()." (mRawPtr != 0) at file ../../../../dist/include/nsCOMPtr.h, line 569 Break: at file ../../../../dist/include/nsCOMPtr.h, line 569 Segmentation fault Why are you so resistant to the patch rginda proposes? It looks ``obviously correct'' to me, and it's clear how we're going to crash if the document comes back NULL.
Assignee: rginda → vidur
Summary: Content with no document causes crash on reflow. → [CRASHER] Content with no document causes crash on reflow.
Assigning to vidur. (Hey vidur, this is the crasher we spoke about at lunch!)
Assignee: vidur → troy
There used to be (and I'm not sure why there isn't anymore) an assert that we had a valid document pointer object. That's fine However, that doens't fix the actual problem. There is a rule that everyone in layout agreed to which is that all content object (including generated content and anonymous content) must have a valid document pointer and parent content pointer. Obviously that's not true in this case, and that problem needs to get tracked down and fixed.
Assignee: troy → vidur
So this is an interesting problem. The way I found to reproduce it is to: 1. click the "Insert 1 k1" button 2. click "Swap Content" button 3. click "Insert 1 k1" button 4. click "Swap Content" button again What is happending is that when we switch content and append k1 back we start to set the document pointer for the nodes in the tree. At some point we get to nsGenericHTMLElement::SetDocument() for a table row. It already has its document pointer set correctly and so we just return. The problem is that not all of its child elements have their document pointer set, and that's why the text frame has no document pointer. The reason is that we did the second "Insert 1 k1" request while k1 was removed from the content model (and k2 was inserted). Re-assigning to Vidur because I think he best understands how this should all work.
In an attempt to get my bug list in order again, marking all the bugs I have currently as ASSIGNED.
I've a temporary fix waiting to be checked in. The problem is that XUL documents runs under different assumptions than HTML regarding newly created content and its mDocument weak reference. HMTL (and generic XML) elements don't have a mDocument until they are part of the document's content tree. For elements created by XUL documents, this rule is violated. As a result, we can wind up with subtrees consisting of mixed content where mDocument is set for some, but not others. The change that I'm about to check in makes sure that SetDocument() calls propagate all the way down a subtree when it's added to a document. The real fix (cc:ing waterson and hyatt per our conversation about this) is to make sure that the mDocument rule for HTML is applied to XUL as well.
Whiteboard: [HAVE FIX]
Target Milestone: M13
Assignee: vidur → waterson
Status: ASSIGNED → NEW
Checked in a temporary fix that allows SetDocument notifications to go down into a subtree even if the document hasn't changed for the root. The real fix still involves getting XULDocument to not set the document of newly created content (i.e. only set the document when it's added to the tree).
Status: NEW → ASSIGNED
Blocks: 23905
Attached patch proposed fix — — Splinter Review
brendan, shaver: gimme a code review on this one. i'm basically doing -exactly- what vidur recommended here (at it seems to work...) 1. Don't set the XUL element's |mDocument| when creating new XUL elements through the DOM API. 2. Be sure to clear the |mDocument| pointer when removing from the content tree. I haven't tested this very carefully yet: I'm going to move it (by itself) to another tree and bang for a while. Let me know if anything seems wrong here. N.B., the nsXULElement::Create() path that takes a prototype element *still* automatically sets the |mDocument|. I think that is the right thing to do: if you're creating something from a prototype, you are -certainly- going to be putting it into a document real soon. I could envision some bizarre problems where a lightweight is removed from the content model, and then somebody tries to invoke an operation that wants to get a the prototype document's script object to compile.... (But no, wait, that couldn't happen, we're not gonna run event handlers on an element that isn't in the document...never mind.)
Priority: P3 → P1
Target Milestone: M13 → M14
Moving the Gordian Knot of 18127, 23905, and 20677 to M14. Fixing this has just introduced way too many instabilities in my tree that it'll take a couple of days to sort out. I'll shoot to get these in when M14 opens.
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash
fix checked in. i ended up being lazy and making XUL elements work like HTML elements. i suck.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Since I not sure how verify this particular problem, could the reporter please check with the latest build. Thanks !
Whiteboard: [HAVE FIX] → [HAVE FIX
Since I not sure how verify this particular problem, could the reporter please check with the latest build. Thanks !
Whiteboard: [HAVE FIX → [HAVE FIX Reporter please check in latest build
The bug itself is fixed, but content don't actually appear until after you force a redraw (ie, iconify/uniconify, cover/uncover.)
Based on the last comments, marking verified fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: