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 (deleted) —
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
Attached file Patch for Range functionality (deleted) —
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: