Closed Bug 13288 Opened 21 years ago Closed 20 years ago

crash from lost content frame in XUL document

Categories

(Core :: XUL, defect, P1, critical)

x86
Linux
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: dbaron, Assigned: waterson)

Details

(Whiteboard: [HELP WANTED] - Waiting on working windows build to verify)

Attachments

(3 files)

DESCRIPTION:  The test document to be attached, with javascript and CSS, crashes
if I load it into apprunner and hit reload twice.  It always crashes as it
appears for the third time (or maybe before it starts to appear?).  I've
replicated the exact sequence of events five or six times.

STEPS TO REPRODUCE:
 * Load attached test case (the XUL file) in apprunner (hopefully it will
   still crash when it's attached and loading over HTTP...)
 * let it load (you'll see a table with five stocks listed)
 * hit reload
 * let it load
 * hit reload
(I'm not kidding!  Those *exact* steps.)

ACTUAL RESULTS: Segmentation fault.  Top of stack trace:

#0  0x40d96353 in FrameManager::RestoreFrameState (this=0x8781cd8, aFrame=0x0,
    aState=0x874de20) at nsFrameManager.cpp:726
#1  0x40db93e9 in PresShell::ContentAppended (this=0x85a66c0,
    aDocument=0x87c93f8, aContainer=0x87ff994, aNewIndexInContainer=0)
    at nsPresShell.cpp:1662
#2  0x40927cdc in XULDocumentImpl::ContentAppended (this=0x87c93f8,
    aContainer=0x87ff994, aNewIndexInContainer=0) at nsXULDocument.cpp:2217
#3  0x40dd4d0d in nsGenericHTMLContainerElement::AppendChildTo (
    this=0x87ff9a0, aKid=0x8800444, aNotify=1) at nsGenericHTMLElement.cpp:2792
#4  0x40dd3fb4 in nsGenericHTMLContainerElement::InsertBefore (this=0x87ff9a0,
    aNewChild=0x8800438, aRefChild=0x0, aReturn=0xbfffd3bc)
    at nsGenericHTMLElement.cpp:2477
#5  0x40dd4668 in nsGenericHTMLContainerElement::AppendChild (this=0x87ff9a0,
    aNewChild=0x8800438, aReturn=0xbfffd3bc) at nsGenericHTMLElement.cpp:2635
#6  0x40dd7ac6 in nsHTMLAnchorElement::AppendChild (this=0x87ff988,
    aOldChild=0x8800438, aReturn=0xbfffd3bc) at nsHTMLAnchorElement.cpp:58

EXPECTED RESULTS: Document loads correctly a third time.

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, 1999-09-05-08-M11
 * Linux, apprunner, my debug build, 1999-09-04
It crashes just as expected off Bugzilla.  Note that it doesn't display
anything (on the second reload) before it crashes.
Assignee: trudelle → danm
Priority: P3 → P1
Reproduced using today's opt build.  In case the steps to reproduce aren't clear
, just go open this bug in mozilla, click on the XUL attachment link, then
reload twice.
reassigning to danm as p1
Assignee: danm → waterson
Summary: crash (XUL related, it seems) → crash from lost content frame in XUL document
Looks like a problem with the XUL document.  The primary frame for
the new anchor element created by the script seems to get lost after
a few reloads.  It happens in XUL, but not HTML.  Reassigning to
waterson, because I'm a jerk, but providing a much more palatable
test case.

The following xul demonstrates the same problem:

<?xml version="1.0"?>
<!DOCTYPE window>
<window onload="DoThing()"
	xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
	xmlns:html="http://www.w3.org/TR/REC-html40">
<html:script>
function DoThing() {
	var anchor = document.createElementWithNameSpace("a",
"http://www.w3.org/TR/REC-html40");
	anchor.appendChild(document.createTextNode("ibm"));
}
</html:script>
</window>

while the equivalent html:

<html>
<head>
  <script>
    function DoThing() {
      var anchor = document.createElement("a");
      anchor.appendChild(document.createTextNode("ibm"));
    }
  </script>
</head>
<body onLoad="DoThing()">
</body>

does not.
Status: NEW → ASSIGNED
Dan, you jerk. dbaron: give me an idea how important this is to get fixed so I
can set the milestone, ok?
It's a code sample in the documentation I'm writing.  Are people going to reload
it three times?  Probably not, unless they decide to use it as a basis for their
own work and start modifying and testing it.  I don't want to pull it out of the
documentation - I'd like to have something just a little complex here and there,
and there are other things that don't work in much more obvious ways that I've
had to avoid.

How hard is it to fix?  (Although perhaps once you know that you'll have done
most of the work...)
Target Milestone: M11
Whiteboard: [HELPWANTED]
Whiteboard: [HELPWANTED] → [HELP WANTED]
bulldozer to M12
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
dlbaron: this WORKSFORME in the current M11 builds; are you still seeing this
as a problem? if so, please re-open.
Whiteboard: [HELP WANTED] → [HELP WANTED] - Waiting on working windows build to verify
This works on Linux6 1999112808 apprunner build.

Also tested on:
Mac86 1999112715 apprunner (talkback) build.

Will mark VERIFIED when Windows build becomes available.
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
Status: RESOLVED → VERIFIED
Marking VERIFIED FIXED on:
- Linux6 2000-02-17-15 Commercial build
- MacOS9 2000-02-17-15 Commercial build
- Win98 2000-02-17-15 Mozilla build

Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: ckritzer → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.