Closed
Bug 48031
Opened 25 years ago
Closed 24 years ago
Crash Browser with improper removeChild
Categories
(Core :: DOM: Core & HTML, defect, P2)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: bc, Assigned: jst)
References
()
Details
(Keywords: crash, Whiteboard: [rtm-][HAVE FIX])
Attachments
(4 files)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m17) Gecko/20000807
BuildID: 2000080712
If you remove the documentElement from a document or remove an Element that has
not been inserted into a document, you will crash Mozilla.
Reproducible: Always
Steps to Reproduce:
Crash 1. document.removeChild(document.documentElement);
Crash 2. elm=document.createElement('a');
document.removeChild(elm);
Actual Results: Mozilla crashes
Expected Results: In Crash 1, perhaps throw NO_MODIFICATION_ALLOWED_ERR, but I
am not sure.
In Crash 2, it should have thrown NOT_FOUND_ERR.
Comment 1•25 years ago
|
||
Doesn't crash in M18 on Linux. 2000-08-08-08.
Reporter | ||
Comment 2•25 years ago
|
||
Just tried with 2000-08-08-08 on Win2k. It no longer crashes on either test
case. Crash 1 removed and returned documentElement and Crash 2 throws a
NOT_FOUND_ERR. Should I just mark this as WORKSFORME or INVALID?
Assignee | ||
Comment 3•25 years ago
|
||
Marking WORKSFORME based on the above comments.
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
OS: Windows NT → All
Hardware: PC → All
Resolution: --- → WORKSFORME
Adding crash keyword for fix and/or verification escalation
Keywords: crash
Reporter | ||
Comment 6•24 years ago
|
||
I was able to crash 2000101320 by removing or replacing documentElement on a
created XML document.
<html>
<head>
<script language="javascript">
var doc = document.implementation.createDocument(null, 'TEST', null);
doc.removeChild(doc.documentElement);
</script>
</head>
<body>
</body>
</html>
nsVoidArray::Count() line 45 + 3 bytes
nsDocument::RemoveChild(nsDocument * const 0x02f0d6ec, nsIDOMNode * 0x00d34090,
nsIDOMNode * * 0x0012e300) line 2906 + 15 bytes
NodeRemoveChild(JSContext * 0x030154d8, JSObject * 0x030818d8, unsigned int 1,
long * 0x02f9f108, long * 0x0012e3b4) line 545 + 25 bytes
<html>
<head>
<script language="javascript">
var doc = document.implementation.createDocument(null, 'TEST', null);
var elm = doc.createElement('NEWTEST');
doc.replaceChild(elm, doc.documentElement);
</script>
</head>
<body>
</body>
</html>
nsVoidArray::Count() line 45 + 3 bytes
nsDocument::ReplaceChild(nsDocument * const 0x02e40f8c, nsIDOMNode * 0x02e39fe8,
nsIDOMNode * 0x02cbc768, nsIDOMNode * * 0x0012e300) line 2831 + 15 bytes
NodeReplaceChild(JSContext * 0x02e16290, JSObject * 0x02d574e8, unsigned int 2,
long * 0x02ecc0c8, long * 0x0012e3b4) line 497 + 34 bytes
Attaching test cases
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 7•24 years ago
|
||
Reporter | ||
Comment 8•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Reporter | ||
Comment 9•24 years ago
|
||
This crash is more general than replacing or removing documentElement.
Document can have Comment, ProcessingInstruction and DocumentType children in
addition to the one Element child (documentElement).
Mozilla 2000101320 crashes when trying to remove or replace any combination of
Comment, ProcessingInstruction or DocumentType.
Attaching testcase where you can choose the means of your crash.
Reporter | ||
Comment 10•24 years ago
|
||
Assignee | ||
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
Nominating for rtm, this is a crasher (admittedly not a frequent one, but still
a crasher) and it's trivial to fix the problem and there's no risk involved in
fixin this, it's just a matter of doing null-ptr checks before referencing a few
pointers.
Priority: P3 → P2
Target Milestone: --- → mozilla0.6
Oy. I think this one was my fault. Sorry.
Patch looks fine (simple null-pointer check). r=dbaron
Adding rtm kw since I think jst meant to.
Keywords: rtm
Comment 14•24 years ago
|
||
Marking rtm need info. This is a low risk fix for a crasher. If we are going
to respin another rtm candidate build, we should take this.
Whiteboard: [rtm need info]
Comment 15•24 years ago
|
||
I've looked at the proposed fix. r=nisheeth. Now, all we need is a super
review from Vidur.
Assignee | ||
Comment 16•24 years ago
|
||
Vidur says sr=vidur, but form talking to PDT this won't become an rtm++ bug (too
low gain), so I'm marking it rtm- and setting milestone to mozilla0.9
Whiteboard: [rtm need info] → [rtm-]
Target Milestone: mozilla0.6 → mozilla0.9
Assignee | ||
Updated•24 years ago
|
Whiteboard: [rtm-] → [rtm-][HAVE FIX]
Assignee | ||
Comment 17•24 years ago
|
||
Patch checked into the trunk, --> FIXED.
Assignee | ||
Comment 18•24 years ago
|
||
Really marking FIXED
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 19•24 years ago
|
||
verified that attached test cases do not crash Mozilla 2000-11-28-04 on Win2k
![]() |
||
Comment 20•24 years ago
|
||
verified linux build 2000-11-26-21
Updated•24 years ago
|
Component: DOM Level 1 → DOM HTML
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in
before you can comment on or make changes to this bug.
Description
•