Closed Bug 414637 Opened 17 years ago Closed 16 years ago

createContextualFragment() throws NS_ERROR_NOT_AVAILABLE

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla1.9beta4

People

(Reporter: nassar, Assigned: smaug)

References

()

Details

(Keywords: regression, testcase)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: XULRunner CVS trunk 01/29/2008

Calls to nsIDOMRange::createContextualFragment() on a HTML document throw the following exception.

[Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMNSRange.createContextualFragment]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: file:///e:/miro/tv/platform/windows-xul/dist/components/jsbridge.js :: anonymous :: line 519"  data: no]

Reproducible: Always

Steps to Reproduce:
    var elt = document.getElementById(id);  //id is a string defined earlier
    var r = document.createRange();
    r.selectNode(document.documentElement);
    var frag = r.createContextualFragment(xml); //xml is a string defined earlier

Actual Results:  
throws NS_ERROR_NOT_AVAILABLE

Expected Results:  
Return the fragment

This is happening for me when I upgrade Miro to XULRunner 1.9 from CVS trunk. The above link is from someone else experiencing the same problem.
Version: unspecified → Trunk
A testcase uploaded using "Add an attachment" would be great.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file testcase
Something to do with .documentElement
mStartParent is null when selecting .documentElement.
Jonas, can you remember something related to this immediately?
Er, no, sorry. It is doc which I QI'd to nsIContent in nsContentUtils::CreateContextualFragment.
That of doesn't work.
s/which I/which is/
regression range 2006-10-19 - 2006-10-21.
-> Bug 357445
Blocks: 357445
Keywords: regression, testcase
Attached file testcase2
So on 1.8 .startContainer is htmlelement, on 1.9 it is htmldocument.
What 1.9 does is afaik right. That is what Opera and Safari returns.

(Safari crashes with this testcase.)
I think we should do something like this.
Assignee: nobody → Olli.Pettay
Status: NEW → ASSIGNED
Attachment #300380 - Flags: review?(jonas)
Comment on attachment 300380 [details] [diff] [review]
allow contextfragments when container is document

Looks good
Attachment #300380 - Flags: superreview+
Attachment #300380 - Flags: review?(jonas)
Attachment #300380 - Flags: review+
Attachment #300380 - Flags: approval1.9?
The patch works for me
Did you want this for b3?
I was thinking after b3. Not so serious, or at least this feature isn't
apparently used very often. So just to get this fixed in FF3.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Attachment #300380 - Flags: approval1.9? → approval1.9+
Checking in content/base/src/nsContentUtils.cpp;
/cvsroot/mozilla/content/base/src/nsContentUtils.cpp,v  <--  nsContentUtils.cpp
new revision: 1.272; previous revision: 1.271
done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
*** 42217 ERROR FAIL | range.createContextualFragment() should throw when range node is DocType |  | /tests/parser/htmlparser/tests/mochitest/test_bug358797.html

Backed out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: --- → mozilla1.9beta4
Bah, sorry.
I'll update either the testcase or patch when back on my dev.machine.
I think changing the testcase is ok, it should just check that 
browser doesn't crash when creating contextual fragment using doctype.
I changed the testcase.
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
Component: DOM: Core → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: