User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20071127 Firefox/18.104.22.168 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.
A testcase uploaded using "Add an attachment" would be great.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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/
Created attachment 300377 [details] 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.)
Created attachment 300380 [details] [diff] [review] allow contextfragments when container is document 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: 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
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
Last Resolved: 11 years ago
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
Last Resolved: 11 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.