212 bytes, text/html
259 bytes, text/html
2.74 KB, text/html
2.18 KB, patch
|Details | Diff | Splinter Review|
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.
Doesn't crash in M18 on Linux. 2000-08-08-08.
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?
Marking WORKSFORME based on the above comments.
Adding crash keyword for fix and/or verification escalation
Mass update of qa contact
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.
Created attachment 17150 [details] Demonstrate crashing using all combinations of removeChild, replaceChild
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.
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.
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.
I've looked at the proposed fix. r=nisheeth. Now, all we need is a super review from Vidur.
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
Patch checked into the trunk, --> FIXED.
Really marking FIXED
verified that attached test cases do not crash Mozilla 2000-11-28-04 on Win2k
verified linux build 2000-11-26-21
QA contact Update
Updating QA contact to Shivakiran Tummala.