Closed Bug 140060 Opened 23 years ago Closed 23 years ago

ReplaceChild on a document's documentElement fails

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla1.1alpha

People

(Reporter: peterv, Assigned: peterv)

Details

Attachments

(3 files, 1 obsolete file)

Open the testcase, you'll get an assertion (###!!! ASSERTION: element not in the
document: 'doc != nsnull', file nsChildIterator.cpp, line 54) and the second
frame will not show content.
Attached file testcase (obsolete) —
That testcase needs to replace "&" with "&" in the iframe src...
Attached file testcase
Attachment #80955 - Attachment is obsolete: true
Attached patch Fix v1Splinter Review
Yeah, yeah. You're to quick ;-).

This should fix it. Looking for reviews.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.1alpha
Hm... is that first change (to SetDocument() after ContentRemoved() to get rid
of the assertion?

Right now, SetToURI and ReplaceChild first SetDocument() and then call
ContentRemoved(), while RemoveChild first calls ContentRemoved() and then
SetDocument().

Which is right?  Intuitively, I'd expect SetDocument (remove the content) then
ContentRemoved, but....
Comment on attachment 80957 [details] [diff] [review]
Fix v1

r=bzbarsky
Attachment #80957 - Flags: review+
Comment on attachment 80957 [details] [diff] [review]
Fix v1

sr=jst
Attachment #80957 - Flags: superreview+
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Something is not quite right on the testcase.  The content from the 1st frame is
successfully imported into the second frame, however, the second frame gains no
scrollbar even though setting focus in the frame and scrolling using the mouse
or keyboard is successful.

Also, clicking "Date" doesn't scroll the frame down to the anchor in the second
frame as it does in the first frame.  In the first frame, viewing the properties
or copying of the "Date" link results in
"http://bugzilla.mozilla.org/attachment.cgi?id=80954&action=view#date" whereas
the same thing in the second frame results in "#date".

Should these findings be reported as a new bugs or are these issues known already?

jake
These need to be reported as separate bugs but I was already planning to file
the second bug and the first one is bug 78070.
Peter, can you post the bug number of the one you are going to report here?

thanks,

Jake
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: