140060 - ReplaceChild on a document's documentElement fails

Status: RESOLVED FIXED

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

Description

[Peter Van der Beken [:peterv]]

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.

Comment 1

[Peter Van der Beken [:peterv]]

Attachment: testcase (helper XML file)

Comment 2

[Peter Van der Beken [:peterv]]

Attachment: testcase

Comment 3

[Boris Zbarsky [:bzbarsky]]

That testcase needs to replace "&" with "&" in the iframe src...

Comment 4

[Peter Van der Beken [:peterv]]

Attachment: testcase

Comment 5

[Peter Van der Beken [:peterv]]

Attachment: Fix v1

Yeah, yeah. You're to quick ;-).

This should fix it. Looking for reviews.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 80957 [details] [diff] [review]
Fix v1

r=bzbarsky

Comment 8

[Johnny Stenback (:jst)]

Comment on attachment 80957 [details] [diff] [review]
Fix v1

sr=jst

Comment 9

[Peter Van der Beken [:peterv]]

Checked in.

Comment 10

[Jacob Kjome]

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

Comment 11

[Peter Van der Beken [:peterv]]

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.

Comment 12

[Jacob Kjome]

Peter, can you post the bug number of the one you are going to report here?

thanks,

Jake