Closed Bug 58970 Opened 24 years ago Closed 22 years ago

Range cloneContents not implemented

Categories

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

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: mail, Assigned: kinmoz)

References

Details

(Keywords: crash, dom2, testcase)

Attachments

(3 files)

BuildID:    20001031

cloneContents DOM 2 Range method not yet implemented

Reproducible: Always
Steps to Reproduce:
1. attempt to cloneContents from a Range returns not implemented error

Actual Results:  NS_ERROR_NOT_IMPLEMENTED

testcase to follow
Priority: P3 → P5
Attached file testcase
Keywords: testcase
Blocks: 58969
Blocks: 49721
Reporter is this still a problem in the latest nightlies? I am not seeing it on
Windows 98 Mozilla Build 2000120604
It is still in the 20001211 nightly... Anthony is working on DOM Range bugs.
You will see the error message in tools -> JavaScript console.
Marking NEW as per reporters comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
setting milestone and priority.
anthonyd
Status: NEW → ASSIGNED
Priority: P5 → P1
Target Milestone: --- → mozilla0.9
finishing up range can be pushed off
Target Milestone: mozilla0.9 → mozilla0.9.1
Keywords: dom2
Component: DOM Level 2 → DOM Traversal-Range
I am attaching a JavaScript "Patch" that can be used as a work around for the 
range object.  This patch adds support for the following:
    Range.innerHTML - read only
    Range.extractContents - as per W3C specs
    Range.cloneContents - as per W3C specs
    Range.insertNode - as per W3C specs
    Range.surroundContents - as per W3C specs
    Range.deleteContents - as per W3C specs - fixes buggy support from Mozilla
    Range.jmyCompareNode - extends Mozilla's compareNode to include
                           the following 2 constants
    Range.NODE_BEFORE_AND_INSIDE = -1;
    Range.NODE_INSIDE_AND_AFTER = -2;

I would like a C++ programmer to implement these in C if possible.

Jeff Yates
Jeff Yates,
It looks like you didnt set the mime type correctly when attaching the patch.  
The patch is just gibberish.  Can yuo please reattach the patch and specify text 
as the mime type? Thanks.
anthonyd
setting milestone to 0.9
Group: netscapeconfidential?
Target Milestone: mozilla0.9.1 → mozilla0.9
Am I missing something here?  Is this a security bug? Why is it marked Netscape
Confidential?
that was an accident
anthonyd
Group: netscapeconfidential?
moving to mozilla1.0
Target Milestone: mozilla0.9 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla0.9.1
So isn't this bug a dup of 58969?
checked in, see 58969
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Reopening bug.

The following code crashes Mozilla 0.9.2 (07-18-2001 build) on Win2k:

var range = document.createRange();
//the next line initializes the range so it can be tested
range.selectNodeContents(document.lastChild);  
var extractFrag = range.createContextualFragment(
              "<b>this is a fragment</b> use to " + 
              "test <b>the cloneContents method</b>");
range.setStart( extractFrag.firstChild.firstChild, 5 );
range.setEnd( extractFrag.lastChild.lastChild, 15 );
var cloneFrag = extractFrag;
if( range.cloneContents )	
	try{ 
		alert("before cloneContents");
		//crashes on the next statement
		cloneFrag = range.cloneContents();    
		alert("after cloneContents");
	} catch(e){}


Jeff Yates
http://www.pbwizard.com
Status: RESOLVED → REOPENED
Keywords: crash
Resolution: FIXED → ---
Depends on: 91614
Did the fix for bug 91614 fix this crash too?
Milestone reality check.
Target Milestone: mozilla0.9.1 → mozilla0.9.4
i think i will go ahead and check in the bug fix to keep this from crashing, but 
it wont fix the broken functionality.
Status: REOPENED → ASSIGNED
clonecontents no longer crashes with a null doc fragment, but it still needs to 
be re-written to work properly in such a case.  this is scheduled for 1.0.
anthonyd
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
This bug needs to be reopened. I can definitely crash Moz 0.9.7 on Win98 in this
manner. I don't know what fixes have been made earlier, but they're not working
any more. 
based on the last few comments in this bug, I am reopening and reassigning to kin
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
handing over to new owner
Assignee: anthonyd → kin
Status: REOPENED → NEW
This was fixed/re-implemented for mozilla1.0 with the patch in bug 120366 back
in March 2002.
Status: NEW → RESOLVED
Closed: 23 years ago22 years ago
Depends on: 120366
Resolution: --- → FIXED
Target Milestone: mozilla0.9.4 → mozilla1.0
cool, I just wnated to make sure of that, marking verified
Status: RESOLVED → VERIFIED
Component: DOM: Traversal-Range → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: